Separate integration devices from other integrations in the integrations tab

[petro]

That’s because whoever made the discovery for that device didn’t make it correctly. MQTT is the only integration that will have that. All other integrations, that would be considered a bug. But because MQTT has the unique ability to create devices via configuration or discovery (which is controlled by the user), then you’ll run into those situations.

EDIT: I.e. if you set up your MQTT discovery information but omit device_identifiers, that’s how it won’t show up in the list.

good

{
   "name":null,
   "device_class":"motion",
   "state_topic":"homeassistant/binary_sensor/garden/state",
   "unique_id":"motion01ad",
   "device":{
      "identifiers":[
         "01ad"
      ],
      "name":"Garden"
   }
}

won’t show up

{
   "name":null,
   "device_class":"motion",
   "state_topic":"homeassistant/binary_sensor/garden/state",
   "unique_id":"motion01ad",
   "device":{
      "name":"Garden"
   }
}

[finity]

I could be mistaken but I thought the difference between a FR and a bug report is that the FR is requesting a change in the intended design? (no disrespect intended…)

But again as long as there is a way to differentiate between device entities coming from different integrations that would meet the spirit of the FR and I’m OK with that.

even just adding an entity attribute like “integration: zwave_js” so we could filter on it would be fine.

[petro]

One other thing, if you know how to abuse identifiers with MQTT, you can attach an MQTT entity to any device. Which is a long standing WTH that many people want to do with template entities.

[petro]

@finity

I could be mistaken but I thought the difference between a FR and a bug report is that the FR is requesting a change in the intended design?

You aren’t mistaken, but this FR is trying to undo the past ~5 years of work. What would be easier? Making something work in the current design paradigm or scrapping it completely like this FR is requesting.

And when I say easier, I’m talking development wise & convincing the people who make these decisions. It’ll be an uphill battle, which is why I said:

@petro

I highly doubt anything will come out of this FR because this is the intended design. I could see some change to the UI to potentially let users know what integration the entity comes from.

the 2nd part of that is implying that something could come out of this if we keep the device page but have a way to show what integration it’s coming from.

[dbrunt (Daniel)]

@petro

Here’s a 1 liner

Is there a way to eliminate the warning in dev tools?

[petro]

ya

{{ states | map(attribute='entity_id') | map('device_attr', 'identifiers') | reject('none') | map('list') | reject('eq', []) |  map('first') | map('first') | unique | list }}

[francisp (Francis)]

I get this:

No tasmota ? No ping ?

[petro]

I thought tasmota just provided discovery for MQTT. So the entities would show up under MQTT. I don’t use tasmota, so I’m basing this off second hand information.

I’m not sure for ping either.

Do this

{{ device_attr('sensor.whatever_ping_you_have', 'identifiers') }}

and post results

[francisp (Francis)]

[petro]

Seems like ping is missing identifiers then.

If identifiers are added… then it’s going to put them onto devices that have the same identifiers.

I.e. if integration a uses IP as an identifier and integration b also uses IP, they will both show up on the same device.

[Ildar_Gabdullin]

I have a bad feeling about this that “identifiers” is a bit uncommon property.

[petro]

I already explained this above

@petro

That will list out all the integrations and the entities. Keep in mind yaml integrations won’t typically show up in this.

Yaml integrations don’t create devices (aside from MQTT), which is why I said “typically”.

I’d wager the ping thing was just the code owner not supplying identifiers. I’d wager an issue should be raised for ping.

[petro]

correction: This is not caused by identifiers, this caused by connections.