#Project Screen naming
1 messages · Page 1 of 1 (latest)
I wouldn't, the device should be my projector screen as a whole, because maybe I have 2 or three. (Lounge room, theatre room etc).
So if my device is called lounge room, and the entity is called screen or mask, then the end result is "lounge room screen" and "lounge room mask"
In my opinion, 1 physical thing shouldn't ever have two devices. If the mask and screen can be removed from each other, only then would it make sense to me.
Thanks. But then I’m not sure how I would comply with the new has_entity_name approach to entity naming? As an experiment, I did just implement the 3 devices approach with has_entity_name=true and it works as expected. So it seems as though this approach would intentionally drive integrations to have a more granular and hierarchical device topology.
What is stopping you from naming the covers "screen" and "mask"?
You mention inheriting name from device. That sounds like using None as name so it would use the name of the device, but that is only when "the entity represents a single main feature of a device", which I think does not apply since you have 2 covers.
Thanks. The reason that I wanted to make the covers more generic was for a couple of reasons. Some projector screens have two covers and others have three (screen, top and side masks) so I didn't want to hardcode too much. Also, the same tubular motor controller can be used for other applications. But I guess that I could rethink that. Before I do though, I have two questions. 1. Let's say that I just had a controller integration that could control N objects. Each object has a main feature and data points "A" and "B". Wouldn't that topology also require a device for the controller and a device for each object? 2. Should I perhaps be creating a dedicated integration for the tubular motor controller and then a separate integration for the projector screen that somehow leverages the first to create a composite device? (Would make sense as the controller and motors are by Nice and the screen is by Screen Research.) Are there any examples of that out there?
Hmmm. Or maybe I just want two separate integrations that leverage the same pypi library under the hood.
If the controller is more like a "hub" that controls multiple separate devices you could make a device for the controller.
But from your description it sounded more like it is one screen that has multiple parts you can control. You would buy it and install it as one device I guess. So from a user point of view I would expect 1 device with a few entities to control those parts.
I am not familiar with other integrations like this. But I also don't know all integrations 🙂