Device Definition

[benhepworth]

Problem description
Discuss a device in commonalities and how that could potentially evolve. Commonalities defines a device as inclusive of a home gateway also. There are potentially different classifications of devices - i.e. a device that connects to a network (phone, Iot device, sensor, etc) vs a device that creates a network or is part of a network (i.e. router, access point, extender, matter hub, cable modem, ONU, etc). @benhepworth to own next steps to drive discussion and take to Commonalities and will include @RandyLevensalor , who has some history with this.

[benhepworth]

current definition of a device in Commonalities:

End-user equipment able to connect to a network. Examples of devices include smartphones, home gateways or IoT sensors/actuators.

initial thoughts - two classifications of devices:

Device - an end-user device that connects to a network. Examples include smartphone, IoT device, TV, watch, computer, medical device, etc.

Network Device - a device that creates a network or is part of a network. Examples include a Wi-Fi router, Wi-Fi Access Point, Wi-Fi Extender, Thread Border Router, Matter Hub, Zigbee Hub, Cable Modem, ONU, Fixed Wireless Gateway, etc.

One though that comes to mind - some devices could be classified as both. For example a zigbee powered light switch which would be a Device that joins the Zigbee network, but also could serve as a Zigbee Repeater.

Thoughts?

[RandyLevensalor]

I'd go with bridge or gateway device rather than a network device. The device is still connected to the network, so it seems a bit confusing.

[caubut-charter]

Feedback on the data model, not the textual description.

We had a lot of debate on this in Matter before landing on Home Routers and Access Points. Our scope is a little different though.

Bridge to me implies a layer 2 device. Gateway may not always be the case (e.g., mesh / extenders).

Some ideas:
API Provider Devices - Access Device, API Provider Device
Consumer Devices - Client Device, Associated Device

Things get a little murky though with protocols like Matter. An API Provider could potentially operate a subscriber's Matter-enabled Wi-Fi router as if it was an API Provider Device.

Due to this, at the data model layer, maybe a better approach is to just use capability flags on a base Device model?

[clundie-CL]

Just some thoughts based on what has been disccussed.

From a definitions perspective, maybe focus it on different "roles" a Device can take on:

Client Device: an end-user device that connects to a network.

• Examples: Smartphone, IoT sensor, laptop, smart TV, wearable, medical device

Infrastructure Device or Access Device: A device that creates, extends, or routes network connectivity or protocol services.

• Examples: Wi-Fi router, Wi-Fi Access Point, Wi-Fi Extender, Thread Border Router, Matter Hub, Zigbee Hub, Cable Modem, ONU, Fixed Wireless Gateway, etc.

Hybrid Device??: A device that participates as both a client and part of infrastructure

and then maybe to your point @caubut-charter , data model could use roles, capabilities, and whatever else needed to capture a specific device's attribute.

[clundie-CL]

Backlog Refinement 1/16/26: Need to align on wireline modifications and submit issue to Commonalities backlog. @benhepworth

[caubut-charter]

Closing #80 and tracking here.

Problem description

Related to review comments included with PR #73

The BaseDevice schema defined in components.schemas.BaseDevice appears to be a partial copy of the Device schema from CAMARA_common.yaml, with the minProperties field commented out. This duplication may lead to inconsistencies and maintenance challenges if the common schema is updated.

Expected behavior
The API should reuse the Device schema from CAMARA_common.yaml directly, unless there is a clear and documented reason for divergence. This will ensure consistency across CAMARA APIs and reduce maintenance overhead.

Alternative solution
If customization is required, document the differences between BaseDevice and the common Device schema, and consider extending or composing the common schema rather than duplicating it.

Additional context
This issue was identified during the CAMARA compliance review. Reusing shared schemas promotes interoperability and simplifies future