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:
- Expose all data retrieved by a single API call.
- Allow for selection if extra calls are required.
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:
- If I don’t specify what I want, I get everything (i.e. like it works now).
- If I do specify what I want, that’s all I get (i.e. an optional constraint).
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.
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.
Yeah, imagine what would happen to the list of devices on a guest network!
Ignore that guest ssid
I can’t really see how it’s a problem, just leave them in unused entities. Like they mention just use Lovelace to show what you want
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.
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/
You expose in lovelace the ones you want visible and nothing else, it doesn’t have to render unused ones anywhere, only if you go into the unused entities page. and that should be rarely
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.