Implement "Device" concept about architecture

[balloob]

Reviewing the proposal and the quotes here, I must say that the idea of devices has grown on me a lot.

As a proposal to implement it, I would think of something like this:

• Add a new property device to the Entity class. Returns an instance of Device class. Defaults to None
• Device class will have properties like manufacturer, model, firmware.
• When an entity is added to an entity platform, check if it has a device, if so, register the device with a Device Registry.

(this proposal would supersede #26)

[OttoWinter]

I've not read through all of this, but @dgomes: For me a use case would be to have an ESP (for esphomelib 😉) exposed as a "device". Because such a microcontroller can have multiple components connected to it. For example an RGB light, a binary sensor and sensor.

The advantage would then be that each "node"/device can then be exposed as a single device and be managed like that.

Not sure if that use case applies here though, as the device concept is as far as I see quite connected to config entries.

[MartinHjelmare]

Some devices eg arduinos will not have standard serial numbers available, nor will mac or ip addresses be available for all cases. I think we should have a general id for each device that is set by the developer as we have unique ids for entities.

Edit: I see now that address is separate from unique id. Nevermind then.

[dgomes]

Would we be able to inherit from Devices ?

See very good candidates:

• Cars
• Personal Weather Stations
• System Monitoring (CPU, RAM, Disk)

[dgomes]

Also relevant: https://iot.mozilla.org/wot/#thing-resource

[balloob]

To continue on my proposal, I realized that there are also devices that on their own do not have entities, but still should be there. For example, the Hue integration communicates with a Hub, but the hub itself is not an entity. Components should be able to also register entities.

It's up to components and devices to specify a unique ID. Unique ID will be scoped by component or platform name. So in the case of light.hue, device will be identified within hue (both component and platform).

It's important that when devices get registered, we know if they are from a config entry. We can then start generating this tree:

• config entry for Z-Wave (will enable component and point at stick)
  • device: 5-in-1 sensor
    • entity: temp sensor
    • entity: humidity sensor
  • device: Z-Wave stick

[balloob]

Device properties

Required:

• Component: string (hue, nest, etc)
• Unique ID: string
• Manufacturer: string
• Model: string
• Connection: string (Wifi, ethernet, Z-Wave, Zigbee, Internet)
• Config Entry ID: string

Optional:

• Address: string = (For wifi/ethernet is MAC, so we can hook it up with device tracker etc)
• Firmware version: string
• Serial NO: string

[balloob]

I wonder how we should deal with things like a TV that can be connected via Plex and via Cast and maybe via a Samsung platform?

Would that mean that the device in that case can be shared among config entries 🤔

[awarecan]

Like a TV can implement multiple interfaces, Plex, Cast and Samsung. In that case, your required properties should change to:

• Unique ID: string
• Manufacturer: string
• Model: string
• Connection: list of Connection Profile
  • Profile Type: string (Wifi, ethernet, Z-Wave, Zigbee, Internet)
  • Profile Data: such as MAC, IP, etc
• Interfaces: list of
  • Component: string (plex, case, samsung)
  • Config Entry ID: string

[balloob]

Good point.

Just realized, we should be able to infer the component from the config entry.

[balloob]

So made a diagram how the different parts relate to one another.

https://docs.google.com/drawings/d/1-wR8t3L1UMRDv9LskH-rDMus4bnvgxa7OeFI_5UZAZ0/edit?usp=sharing

[balloob]

For matching up, we first check for serial match, after that we look for a match for one of the connections. Not sure if we should differentiate between wifi/ethernet because we might not know.

[dgomes]

"Device can be shared between two components"

In the diagram, this use case is depicted by Device C. Device C connects to two entities belonging to Component A (Example: TV that runs two media_players).

Now I'm wondering about Device D which connects directly to Component B (example: Hue registers the Hub).

Do we have a use case for a Device that connects directly to TWO Components ?

[balloob]

The only thing I can think of is something like a server that is running a bunch of stuff.

[dgomes]

@OttoWinter but would it be connected to the component or to the entity ?

I'm fine with any answer, I'm just concern with handling the consistency of all these relationships, especially those that are any-to-any.

[balloob]

It's not connected perse to config entries, entities could come from configuration yaml or discovery. Although for discovery we'll have to talk about how to define a device.

I prefer for it to be evolving around config entries because each entry represents authorization to access a service/set of devices and that makes a nice UI.

Wondering now if we should allow IP addresses as temporary identifiers, as Mac is not always accessible

[awarecan]

I met a challenge may fit for Device to resolve.

In Nest, it break up to tons of sensors, for each Nest Device, we have a binary_sensor.online. So, in case network connection has issue, I want to use this sensor to cutoff other sensors/climate/camera's state update process to avoid flush event loop.

If we have Device, and it has a property say online, then everything will become very easy and clear, we should first check device's online status (no matter it maps to a separate sensor or not) before try to update any other Entity's state.

[balloob]

The data flows from the integration to the device and entities. An integration provides the info and so doesn't need to check device

[Adminiuga]

How do we go about a "technical" or "debug" information for a device? For example, in Zigbee world it would be tremendously helpful to have information like: Link Quality Indicator, Last Seen, Neighbors etc, which may change quite frequently, but not necessarily should trigger a state change event.

Or as another example a device representing a "network interface". it is helpful to have debugging information, like number of packets in/out, number of CRC errors, dropped packets etc.

In other words information that you don't need when everything is working fine, but is really needed during troubleshooting/error reporting

[dgomes]

@Adminiuga those are sensor entities (as they currently are), which you can associate to a Device.

[balloob]

I think that such data is out of scope. Zigbee should just get their own panel like Z-Wave and make these things available. There is no need to add that to the core of HASS.

[Kane610]

So I've started playing around with a device registry and there is one main thing Im trying to grasp in this design; how the actual coupling of device and entity would work. Is it enough with the device to keep a list of entity ids? Or should there be direct references to the entity objects? (Im guessing this is a big no no)

[awarecan]

Why no, I would say object reference. entity_id can be changed by user.

[balloob]

I would expect it to be linked as follows:

• Each entity has a new property device. This property is read when an entity is passed to the Entity Platform's add_entities inside async_setup_platform/async_setup_entry
• The device is processed in the registry, either retrieving an existing registration or creating a new one
• The entity registry will store a device id.

This means that entities that do not have a unique ID cannot be linked to a device but that makes sense. If we cannot figure out if we've seen an entity before, we can't store that data either.

[Kane610]

I'd like some feedback on my initial alpha draft of device registry whether I'm in the right ball park and general comments. Also if I've misunderstood any points in the discussion above.

Thanks!

[Kane610]

Initial documentation home-assistant/developers.home-assistant#81

It does need comments. Maybe we should add Paulus excellent diagram to it?

[balloob]

Yes we should! Closing this as it's considered done.