jncanches
Wonderful release! Will fit my new RPI 4 perfectly 
thank you guys!
Wonderful release! Will fit my new RPI 4 perfectly thank you guys!
I made this change last night for a completely unrelated issue. It went smooth but be aware that your entity ids may change. Mine were still in the older style and were updated after going the integration route.
So sensor.zwave_device002 May become sensor.z_wave_device_002 for example. Not a big deal but the change can be a hassle to carry through a large config.
Any idea why the docker image has grown by 0.5GB between 96.5 and 97? Seems like it’s carrying a lot more libraries or something?
What document in the Fortinet Developer Network is needed to explain creating an API token for the fortios device_tracker? Nothing I’ve tried seems to work.
Does anyone know what happened to custom-css? It used to work fine before but since 0.97 it doesn’t work anymore. For example in my themes.yaml file I have a custom property say
test-color: '#FFFFFF'
And a button with the style configured as:
style: |
ha-card {
background: var(--test-color);
}
This used to work fine when setting a theme via the profile menu in the interface via the sidebar. It still works, but only if I do a service call and set frontend theme, it used to be instant, now it requires a refresh (not a big deal). But doing a service call to set the frontend theme will set that theme for all users as it will be the backend-selected theme.
It just does not work when changing it through the UI, the wallpaper will change but it will not accept any of the custom properties. I know it is probably the wrong/bad way to do it. But it works haha.
Thanks for any info on this.
Translation:
If you want to perform a Config Check, reload automations, restart the server, etc then all of these commands have a new home in Configuration > Server Control.
Thank you @IcyPalm. It’s nice to, once again, have Config Check located at the top of the page.
Congratulations and thanks to all developers for another great release. 
nest isn’t working with set temperature getting the following error:
`expected float for dictionary value @ data['temperature']`
Can someone tell me where the configuration checker went? I used to be able to set the advanced mode in my profile. It’s on, but I don’t see the option to check my configuration through the ui anymore.
Edit: did not see the new menu option where the items are moved to now.
I really wish that these upgrading breaking changes were a bit better documented. Because the way it’s done right now, for example in the unifi setup, is to say feature X changed and it points to docs which say how it’s set up now. But what’s missing is an example of what the previous config should look like now i.e. how to migrate the config.
This could be solved by requiring these examples to be included in the PRs.
Another example using the unifi integration
Options to not track wired clients
This is nowhere documented, the word “wired” doesn’t come up in the docs at all.
A great example of what I’m talking about take a look at the django breaking changes releases and their documentation, which provide old code example and how to achieve the same (if possible) with the new version.
But regardless, thanks to all contributors for the new release!
1 reply
Does the configuration.yaml need amending for reloading themes? Or will this just work as and when I make changes to the themes?
Anyone having trouble restoring Hassio snapshots on 0.97? I can’t roll back to 0.95.4 and I haven’t had issues using snapshots before.
Probably the podcast, bit hard to have them show their config on that.
I’ve tested the reload scenes feature is working well for me, I’ve managed to give it a go by calling the scene.reload service in the dev tools.
Would it be possible to add a ‘Reload Scenes’ in the webinterface alongside “Reload Core, Reload Groups, Reload Automations, Reload Scripts”? This may already be planned but I thought I’d ask for it if it’s not. Thanks
How do I set up the new google calendar ?
I tried this but get a config error - Platform not found: calendar.google
Docs link in the release blog point to google TTS
calendar:
platform: google
client_id: YOUR_CLIENT_ID
client_secret: YOUR_CLIENT_SECRET
Don’t know, my calendar integration is gone - just getting errors in the log. But didn’t have time to play with them yet.
According to release notes, there are some breaking changes but they should be limited to automations in regard to calendar, not calendar itself.
Yes I read that and think its just the google calendar docs not updated, if you look at the caldav ones that’s where I got the idea of calendar: platfrom google. Guess we’ll have to wait until they are updated
1 reply
Caldav with icloud has been broken for months now. So I don’t know what is wrong with it. Hopefully google calendar doesn’t face the same fate.
This is where I saw the change (above)
After upgrading to 0.97, the ROKU platform is creating the following error:
2019-08-08 07:29:45 ERROR (MainThread) [homeassistant.setup] Error during setup of component roku
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/setup.py", line 172, in _async_setup_component
component.setup, hass, processed_config # type: ignore
File "/usr/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/roku/__init__.py", line 56, in setup
_setup_roku(hass, config, conf)
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/roku/__init__.py", line 97, in _setup_roku
from roku import Roku
File "/srv/homeassistant/lib/python3.7/site-packages/roku/__init__.py", line 1, in <module>
from roku.core import Roku, Application, Channel, RokuException, __version__
File "/srv/homeassistant/lib/python3.7/site-packages/roku/core.py", line 4, in <module>
from lxml import etree as ET
ImportError: libxslt.so.1: cannot open shared object file: No such file or directory
My setup is: Hassbian (Buster), Python 3.7
Under Beta Fixes I see @pvizeli made a change
Anyone know how I can fix this?
Agreed 100%. And I think it goes beyond the upgrade examples. The HA documentation in general is more like a programmers reference guide, often showing the minimum amount necessary to get the idea across (i.e. assuming that someone is quite knowledgeable about HA, it’s syntax, etc).
I’ve been running HA for over a year and still struggle considerably with even simple stuff - usually relying on finding other forums discussions, or digging through github to find example configurations.
With 1.0 quickly approaching, the massive publicity will draw massive numbers of new people, and the forums are going to be flooded with simple questions that could have been answered via more complete examples in the documentation.
Got my google calendars working again, just used the original
google:
client_id: YOUR_CLIENT_ID
client_secret: YOUR_CLIENT_SECRET
in config yaml and restarted and got a notification about setting up calendars, copied the code and it went to google to authorise the connection. No idea why it stopped working but works now
1 reply
Home Assistant Podcast 54 – 0.97 and making beer with Brandon
“Brandon” was interviewed. They typically have a guest on their podcast on youtube
1 reply
shell_command is crashing my HA. I see other mentions of something similar here: Shell_command crashes interface on > 0.95
any idea what could be causing this?
I have the same issue, in the logging I see the following:
2019-08-08 18:05:19 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 400, in _async_add_entity
await entity.async_added_to_hass()
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/filter/sensor.py", line 258, in async_added_to_hass
for state in filter_history[self._entity]
KeyError: 'sensor.power_consumption1'
This was working before the update
The config part is the following:
- platform: filter
name: 'power_consumption_filtered'
entity_id: sensor.power_consumption1
filters:
- filter: time_throttle
window_size: 00:0:15
precision: 3
I don’t understand the UniFi presence detection changes. After upgrade, devices on my unifi network all show as away. What needs to be changed in my config for this latest update?
EDIT: Looks like it just adds all the devices by name on the router so I will have to change the names of some of my entities that I had pre-configured.
3 replies
I wonder if this renaming only occur if you have a UniFi router?
I have a couple of UniFi access points and UniFi switches and use pfSense as the edge router that hands out DHCP leases to clients. Tracking these devices by MAC address has worked really well for some time, I hope that continues to be the case.
I have a USG and that is the integration that gets all the names and other connection info. The change is that all items in that router now show as device trackers along with the name I assigned that device in the USG.
Good for you. I’m restarting it now for 3rd time…
That part of the configuration is same as it was before. Only thing I removed was password part for Google Maps tracking (as per breaking change in 0.97), but… calendar is still not working.
2019-08-08 21:08:53 ERROR (MainThread) [homeassistant.components.calendar] Error while setting up platform google
Traceback (most recent call last):
File "/usr/src/app/homeassistant/helpers/entity_platform.py", line 149, in _async_setup_platform
await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for
return fut.result()
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/google/calendar.py", line 34, in setup_platform
for data in disc_info[CONF_ENTITIES] if data[CONF_TRACK]])
File "/config/custom_components/google/calendar.py", line 34, in <listcomp>
for data in disc_info[CONF_ENTITIES] if data[CONF_TRACK]])
File "/config/custom_components/google/calendar.py", line 47, in __init__
super().__init__(hass, data)
TypeError: object.__init__() takes exactly one argument (the instance to initialize)
Didn’t find anywhere that cookie or authentication or whatever have to be delated and re-authenticated…
1 reply
One thing I noticed is you’re using the custom component Google calendar, I’m just using the built in one.
1 reply
Just updated to 0.97
Getting lots of errors for some (not all) of my media in helpers/entity.py complaining about missing entity-id for my media’s various switches such as “repeat switch”, “do not disturb switch”.
Here is an example:
2019-08-08 15:12:03 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/opt/homeassistant/venv_3.6/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 243, in async_update_ha_state
"No entity id specified for entity {}".format(self.name)
homeassistant.exceptions.NoEntitySpecifiedError: No entity id specified for entity MY Fire TV Stick repeat switch
WOW!
After upgrading I now have a gazillion device_trackers!
How do we white-/blacklist device_trackers with the new Unifi tracker?
Right now I have a device_tracker for every single connection (and servers with 2 or more connections are presenst multiple times!)
2 replies
Yes, you are right, but I’m using generic Google calendar for component and custom component is just for visualisation (you have to have generic one working for it).
same here it’s screwed all my device tracking and several media players (custom component alexa and tivo for starters)
This is what I’m trying to figure out - it is made out to be a switch to block users (but no switch appears).
Thank you! Went looking for it and thought it was gone again!
For presence detection with the UniFi component (or any presence component…), defaulting to creating device trackers for every single discovered device on your network doesn’t seem like the correct default behavior. At least with the old UniFi device_tracker, you could tell it to no track by default, and it only polluted a single file with all the new devices that appeared over time on your network.
If we’re heading towards a 1.0 release that’s going to appeal to a new segment of “non-early adopter” users, I would imagine the only device_trackers they (and others) would likely be interested in are those associated with “personal devices” like mobile phones, tablets and maybe a laptop. Or maybe your wi-fi connected car.
I wouldn’t think most people would care about all the other random devices on your network as a default choice. Isn’t this a pretty big regression as compared to the previous component?
1 reply
In ADR 0006: Docker Images it says “… some things are not supported on Alpine. For example, TensorFlow …”. But in 0.97 release notes it says that “You don’t need to change anything unless you have installed Debian packages manually or made any other changes to the running container”.
Will Tensorflow break on 0.98? 
My base OS is Ubuntu/Debian 
So if I understand correctly - the Tensorflow component in Home Assistant will still work? Or do you mean that Tensorflow must be run in a separate docker container?
Hey, thanks for the update!
I clicked the Update button in Hassio but since then (15 min) I haven’t been able to connect to hassio.
I’m trying to figure out what can be wrong, I’m using a rasp pi 3 b+ that was connected to my network over wifi.
Could that be a problem, that it’s connected to wifi only?
What else can I do to see the log of what’s going on?
Any help is appreciated, thanks!
1 reply
Okay so an update of my progress in case anyone has a similar problem.
I restarted the pi. Was still unable to connect to hassio so I plugged in a network cable and then I was able to connect to hassio.
I still had the old version (0.96.5) so I tried updating again, now with the network cable connected I could still enter the system log.
19-08-09 12:43:12 INFO (SyncWorker_11) [hassio.docker.interface] Update image homeassistant/raspberrypi3-homeassistant:0.96.5 to homeassistant/raspberrypi3-homeassistant:0.97.0
19-08-09 12:43:12 INFO (SyncWorker_11) [hassio.docker.interface] Pull image homeassistant/raspberrypi3-homeassistant tag 0.97.0.
After 5 minutes the update was done.
It never showed me the web page.
I can access it by samba, but ssh is not configured to run at boot (major error).
I don’t have an external monitor, so i guess i have to reinstall it…
My configuration had just a couple of things, it’s not a major deal to reinstall.
But i will think twice next time an update is available via the web page.
The breaking changes to the Ecobee thermostat have destroyed required thermostat functionality. The thermostat implementation previously had two variables, climate_mode and preset_mode. These tracked the schedule of the thermostat and the hold mode of the thermostat. The change has bundled these two variables together. Now you can’t cancel an indefinite hold when a schedule change occurs for example. I don’t see the point of this breaking change.
1 reply
I find the new UniFi component a huge positive change. Details about each device is really useful for future endeavours. Besides that it also means a cleanup of various legacy yaml code for me personally. Leaner and meaner in the end.
The initial work was however not clear from the sparse information provided. Impact of this braking change is simply not really known beforehand, you have to dive into an upgrade. IMHO the impact should be more clarified to us - the end-users - or at least point to the right resources.
Excactly my point - I’m not interested in all 200-ish devices on my net, only our mobile phones are interesting.
Before the upgrade I could tell the system to not track anything by default, and then go in the known_devices.yaml and allow tracking of specific devices - can’t find that option after the update.
@gregbm looks like you are familiar with Ecobee. Please open an issue and tag me so we can discuss how Ecobee can work better with the new format for climate in Home Assistant. I was under the impression that hold would be shown as the preset mode, while a hold mode can be canceled by picking a comfort mode from the available presets
Therein lies the problem. I use the UniFi component today, and it’s the most reliable means of sensing presence for me. Thus how I view this as a regression, lacking the ability to selectively control which devices are tracked, like was possible previously.
I don’t need to use Home Assistant as some sort of network management platform to monitor the availability of all the devices on my network; there are other much better, more appropriate tools to solve that problem.
1 reply
I don’t see how having all the devices listed is a problem. Yes, we lost functionality with this update, but it’s far from being critical or something to get worked up over.
I find it really a sad statement on some people to hear them whine and moan so much over FREE SOFTWARE that others are working hard to provide.
3 replies
I don’t care about having all devices listed. It’s the fact that the device tracking has stopped working full stop for me, and for others too.
2 replies
What has stopped working with device tracker?
Was there a breaking change to Alexa Media Player? After upgrading I’m getting this:
Unable to prepare setup for platform alexa_media.media_player: Platform not found (cannot import name 'MEDIA_PLAYER_SCHEMA' from 'homeassistant.components.media_player' (/usr/src/homeassistant/homeassistant/components/media_player/__init__.py)).
I think there is an update to the add-on to cater for thast particular issue
1 reply
Ok, Thanks. I will look into that.
It’s working fine. Names may have changed but if you update to the new names; or rename the entities to the old names; it all works as it did.
Really?
So you think that to show our dislike for a new feature or loss of functionality is just people whining? How do you recommend that people voice a problem that they are having and what they think is a better idea? Or is it you don’t think people should voice any negative thoughts at all? How do you think a developer will know that there is a problem unless we (the users) let them know?
I’m not sure that a loss in functionality should be a goal of any update. Loss of functionality should only ever be the result of things completely beyond the control of the developer. I’m not saying that the loss of functionality was a goal in this case (it’s more likely to be a bug) but if losing functionality is built in then that’s not a good thing and deserves a “complaint”.
3 replies
I’m sure it’s not the goal at all. Has any functionality actually been lost or is it just a change in the way it’s presented/configured?
2 replies
Be constructive and go file a GitHub issue if it bothers you so much…
An exclusion filter has been dropped so you end up with additional device_trackers for all your wifi and wired clients. Not a big deal and just a nuisance issue if you don’t want them exposed.
I don’t see it as whining. Pointing out how an update affects users (good and bad) is the whole idea of these version update topics. Many things have been fixed this way. e.g. the recent changes to the side menu.
It’s a minor nuisance to you but highly annoying to others.
Also thank you for the reply to my question above. That was precisely the information I needed.
Breaking Change concerning VeSync devices:
Remove it from sensors platform in Yaml and it’s now it’s own integration from what I understand as
vesync:
Brought all mine back to life after Yaml modification and reboot. Took me a minute to find the new configuration validation- Left menu Configuration and then under “Server Control”.
I see that almost all of the monitored conditions have been removed from the Unifi Tracker and there is no way to put them back in. It would be nice to be able to selectively put those conditions back in as I used ap_mac to determine what device was in what location and have a lot of frontend UI stuff built off of that as well as automations.
Right now it’s all just broken.
Also, having the device_tracker entities still show up in the States tab, even after deleting them out of the Entity Registry is kind of frustrating. I have a lot of network devices and I don’t want or need all of them showing up in HASS. 
Regarding Unifi device tracking - You can filter out all wired clients by adding dont_track_wired_clients to the config. Not sure why this hasn’t made it into the docs yet, but it is working for me…
# Example configuration.yaml entry
unifi:
controllers:
- host: unifi
site: My site
dont_track_wired_clients: 'true'
ssid_filter:
- 'HomeSSID'
'IoTSSID'
Tile device tracker no longer works in 0.97.1
Error setting up platform legacy
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/device_tracker/setup.py", line 69, in async_setup_legacy
hass, self.config, tracker.async_see, discovery_info
File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/tile/device_tracker.py", line 74, in async_setup_scanner
return await scanner.async_init()
File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/tile/device_tracker.py", line 98, in async_init
await self._async_update()
File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/tile/device_tracker.py", line 129, in _async_update
gps=(tile["tileState"]["latitude"], tile["tileState"]["longitude"]),
KeyError: 'tileState'
From the linked Architecture issue:
Integrations should expose all available data to the backend if that data is fetched in a single API request.
Integrations should only include selector logic if it make sense in the context of interface, like if it would require extra requests.
It all seems reasonable:
One of its stated goals is to simplify the user’s life:
User should not have to read the available documentation and API descriptions to find out which data they want have.
My suggestion would be that if a user has read the device’s documentation and knows precisely which data they want then they should be allowed to select it. In other words:
So the default behavior remains the same (expose all data retrieved by a single API call) unless the user (knowledgeable with the device’s capabilities) restricts the scope of the retrieved data.
I’m literally not the one who said that any functionality has been lost. That was the person I was replying to who described it as:
I was just pointing out that it is silly to refer to the people who posted replies to this topic that indicated that they weren’t happy with a change that was made as “whiners”. I didn’t even post a reply that criticized the release in any way (I don’t even use the Unifi integration…yet) and yet I was specifically and personally called a “whiner”. I think it’s ironic that some who call out others for not being “constructive” will then turn around and start calling other forum members names. If I’m not mistaken that is somewhat less than being “constructive”.
I really don’t see the problem in people pointing out, in a thread specifically created for a new release, that they are having problems with something included in that release. And if more people join in saying they don’t like something then the more likely it will be to get resolved. That doesn’t make anybody a “whiner”.
Most people aren’t even sure if it’s a bug or a feature until they post on here and ask. I know I for one don’t start trying to find answers to questions like that by attempting to scroll/search thru the list of 800+ issues on the github. I start here first.
Ayy lmao where’s that crew who jumped me and told me there weren’t any when I said we need to address the condescending folks with bad attitudes/poor bedside manner on this forum? 1.0 is getting closer, is this what we want version 1.0 of the community to look like?
Same here, almost the same code, I am running Hassio 0.97.1:
- platform: filter
name: "DSMR Huidig Verbruik"
entity_id: sensor.power_consumption
filters:
- filter: time_throttle
window_size: 00:00:30
precision:
The log shows:
2019-08-10 18:22:08 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 400, in _async_add_entity
await entity.async_added_to_hass()
File "/usr/src/homeassistant/homeassistant/components/filter/sensor.py", line 258, in async_added_to_hass
for state in filter_history[self._entity]
KeyError: 'sensor.power_consumption'
Disabling entities is no longer going to be the responsibility of integrations but of Home Assistant core via the entity registry. Disabled entities will no longer be added to the state machine.
As a user you should not aim to manage what is in the state machine. With Lovelace you pick and choose the entities that you want to see.
2 replies
How are they disabled? I find if I delete an entity, if the integration that created it exists the entity will come back when you next restart?
That will be nice to be able disable entities, will it also be possible to disable/blacklist integrations? Or would it be best to disable every entity for that integration.
Being able to disable entities instead of deleting them sounds ideal. A delete option is still needed for entities/integrations that no longer physically exist though.
I often experiment with ESP modules and find that when re-using a module previous entities are not deleted correctly from the registry when using the GUI, which then requires manual editing of the .storage files.
If the list of possible entities was fixed or bounded, I can see how this can be done as described, by some manual action at the time the integration is enabled and during some setup process.
However, in this case, the possible entities are completely unbounded (e.g., a zillion possible MAC addresses) and it’s not possible to disable all the possible unwanted/unneeded entities at the time the integration is configured.
In this situation with the UniFi integration, there’s going to be an ongoing addition of new entities as random devices connect to the WiFi network over time. This creates a poor user experience because it created now an ongoing maintenance issue of having to periodically disable/delete the new unwanted entities. Because there’s no “don’t add by default” option available. All because I want to track only two single MAC addresses on my WiFi network.
Please don’t let the attraction of some architectural purity ruin how people use the platform. For many people, this approach causes the integration to be much less useful. I shudder to think how much worse this will be for a Bluetooth-based tracker that will pick up even more random devices since there’s not even a filter of a Wi-Fi password to reduce the possible population of devices.
1 reply
Ignore that guest ssid
It’s just going to clutter up my system with a bunch of extra entities that are just there to be confusing and distracting. My front-end already sorta goes slow in some of the lovelace dialogs when it’s constructing a list of entity_ids… adding another bunch in there isn’t going to help.
And also, it’s not just the Lovelace UI that’s got to ignore these things. It’s the recorder/history database. Worse, its influxdb where all these entities are going to create a new series for each device_tracker entity, and the number of different series that exist is a scaling thing for influxdb. So now I have to individually list only the device_trackers I’m interested in when configuration that component. So I don’t need to use a text editor to manage my UniFi integration, but I will need to use it to edit my influxdb component and explicitly include individual entities now.
My known_devices.yaml file has 164 mac addresses that have accumulated over the last few months; I try to truncate it and strip out the random ones that appear a couple times a year. I’d imagine that Home Assistant is going to accumulate a couple hundred extra entities and associated persistent state. At present I have 331 entities in Home Assistant. Why would I add 150 or 200 extra useless ones to the mix? Or do I get to manually disable/delete these things, one at a time, in a UI to hide them? How’s that a great UX? I only want to track two MAC addresses? Why is Home Assistant making this a burden where it wasn’t before?
It would be one thing if the extra entities were fixed and unbounded (like a selection of weather data, like wind chill that I might not be interested in.) That’s a one-time activity. The MAC addresses exposed by the UniFi platform are not fixed and unchanging; I can’t just configure it once and delete the handful of extra data I’m not interested in. The extra data might be 100 entities at the outset, and then continue to grow in an unbounded way in the future.
It’s a poor architectural design to just needlessly grow all this state for no good reason. It’s going to clutter up and confuse, slow the UI rendering and UX interaction as it constructs a list of all these pointless entities that are just going to hide the ones the user’s looking for.
2 replies
Is it not possible to still use:
new_device_defaults:
track_new_devices: false
The UniFi thing is an integration now, no longer a platform specified in device_tracker. Or at least that’s how I interpret the documentation at https://www.home-assistant.io/components/unifi/
if it’s anything like the geo_location integration, I fear it’s not as impact-less as you suggest.
Had over 2 thousand lightning strikes, and even without showing these in the frontend on a dedicated map, it practically killed the HA instance.
Having many, many unneeded but tracked entities is to be prevented.
but with things like that you are listing them explicitly as entities to be shown on a map in a view.
Well hopefully the next reiteration of the unifi integration will allow further exclusions as the next doco has this listed as options.
dont_track_clients:
description: enable to not allow device tracker to track clients.
type: boolean
required: false
default: false
dont_track_devices:
description: enable to not allow device tracker to track devices.
type: boolean
required: false
default: false
dont_track_wired_clients:
description: enable to not allow device tracker to track wired clients.
type: boolean
required: false
default: false
No, if you read my post above, I noticed that even without doing so, all entities were created, and tracked, which is exactly what this component does. Idealy we should always be able set track/not-track devices, or in this case even track/not-track new devices.
Keep the HA instance as clean as possible. Especially since the Pi is one of the adviced devices, maybe even advised device no 1.
Post edited above (hit replybefore other information added)