UDMI / Docs / Specs / Compliance
This is an overview of what it means for a device to be “UDMI Compliant.” There are several different facets to UDMI, each providing a different bit of functionality, so the actual requirements will depend on the intended function of the device.
The Tech Primer gives a primer for smart-ready building assembly requirements
The feature buckets list classifies the defined functionality within the UDMI specification into individual features and buckets. This aids in assessing levels or completeness of compliance of a device and can be used for defining requirements.
multi_enumeration
- ..empty_enumeration
- ..pointset_enumeration
- ..features_enumeration
- ..family_enumeration
- ..discovery_scan
- Rejects bad hashMQTT 3.1.1 support
- Device supports MQTT 3.1.1MQTT/TLS Support
- Device supports connection to an MQTT broker with TLS encryption and at least TLS v1.2Server certificate validation
- Device validates MQTT broker server certificatesMaintains Connection
- The device can connect and sustain a connection to the MQTT brokerNetwork resumption reconnection
- Device reconnects to MQTT broker when connection is lost, or reattempts connection if connection attempts are unsuccessfulExponential backoff
- Device reconnects to MQTT broker when connection is lost, or reattempts connection if connection attempts are unsuccessfulJWT
- Device is able to authenticate to an MQTT bridge using JWT credentials in the password and renewUser configurable connection
- Connection parameters (including client ID, hostname, port, etc) are user configurableendpoint_connection_bad_hash
- Rejects bad hashendpoint_connetion_success_alternate
- Can successfully connect to alternate endpointendpoint_connection_success_reconnect
- Reconnects to the new endpoint, after restartendpoint_connection_retry
- ..device_config_acked
- Device subscribes to the config topic with a QoS 1 and always publishes PUBACKs to the brokerState after configuration
- Device publishes state messages after receiving a config messagesystem_last_update
- system.last_update field in state messages matches timestamp of last config messagebroken_config
- The device remains functional when receiving a config messages which is invalid at a core level (e.g. invalid JSON, missing fields required fields such as top level timestamp), retaining the previous configextra_config
- The device remains functional when config messages contains fields which are not recognized by the devicesystem_min_loglevel
- Configurable min log level for filtering published status/logging informationsystem_hardware
- Hardware block is included and the contents match the physical hardwaresystem_software
- Software block in state messages is included, with keys and values automatically generated by the device matching the software versions installedvalid_serial_no
- Serial number in state message matches physical hardwaresystem_mode_restart
- device restartssystem.config.receive
- Device publishes a logentry when it receives a config updatesystem.config.parse
- Device publishes a logentry when it parses a config updatesystem.config.apply
- Device publishes a logentry when it applies (accepts) a config updatesystem.base.startup
- System startup events are loggedsystem.base.ready
- System fully-ready events are loggedsystem.base.shutdown
- System shutdown events are loggedsystem.network.connect
- Network connection events are loggedsystem.network.disconnect
- Network disconnection events are loggedsystem.auth.login
- Successful logins to device application are loggedsystem.auth.fail
- Failed authentication attempts to device application are loggedpublish
- Device publishes system metricsschema
- metrics valid with UDMI schemametrics_rate_sec
- Implements metrics_rate_sec to configure sample rate for metricsPublish
- Publishes pointset event messages with a valid schemaDatapoint mapping
- Mapping of UDMI data points to device-internal data points is through config messages, allowing points to be renamedPointset Config
- Pointset is configured through UDMI, only publishing points which are in the config, and the points are in stateOffline buffering
- Telemetry events while device is offline are stored and published when connection is resumedpointset_sample_rate
- Sampling rate for the system, at which it should proactively send a complete pointset within the pointset.sample_rate_min
, defined in the config messagepointset_publish_interval
- Minimum time between pointset events is defined by pointset.sample_limit_sec
in the config messagePartial updates
- Supports partial updates (with partial_update flag set to true)Configurable CoV Increment
- Configurable CoV increment per point through UDMI Configsample_limit_sec
- Limit sample sec