> For the complete documentation index, see [llms.txt](https://docs.cybus.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cybus.io/2-6-1/connectors/shop-floor-connectors/shdr.md).

# Shdr

Capture process data, conditions, alarms, and events from MTConnect adapters when no MTConnect Agent is available.

Shdr is the underlying protocol of MTConnect, which implements the communication between an MTConnect Adapter and MTConnect Agent.

In situation where no MTConnect Agent is available, you can directly hook into this communication. The protocol is readonly and reports all process data of machines including conditions, alarms and events.

Important

For addressing data in Shdr, you first need to know the keys of the data items. These may be one of the following (in this order): Source, name, id of the item in the MTConnect Information Model of your equipment.

To learn about the available keys on your equipment without the MTConnect Information Model being available, subscribe to *raw* data and observe the data over time.

## Service Commissioning File Specifics

A typical service commissioning file for the SHDR protocol looks like this:

{% file src="/files/MYCkv47S3WOEsO73AoMG" %}

{% code title="shdr-example.yml" lineNumbers="true" %}

```yaml
# ----------------------------------------------------------------------------#
# Commissioning File
# ----------------------------------------------------------------------------#
# Copyright: Cybus GmbH
# Contact: support@cybus.io
# ----------------------------------------------------------------------------#
description: >
  Shdr sample commissioning file

metadata:
  name: Shdr simulator
  provider: cybus
  homepage: https://www.cybus.io
  version: 1.0.0

parameters:
  IP_Address:
    type: string
    default: 192.168.0.1
  Port:
    type: integer
    default: 7878
  initialReconnectDelay:
    type: integer
    default: 1000
  maxReconnectDelay:
    type: integer
    default: 30000
  factorReconnectDelay:
    type: integer
    default: 2

definitions:
  MQTT_TOPIC_PREFIX: io/cybus/shdr

resources:
  shdrConnection:
    type: Cybus::Connection
    properties:
      protocol: Shdr
      connection:
        host: !ref IP_Address
        port: !ref Port
        connectionStrategy:
          initialDelay: !ref initialReconnectDelay
          maxDelay: !ref maxReconnectDelay
          incrementFactor: !ref factorReconnectDelay

  raw:
    type: Cybus::Endpoint
    properties:
      protocol: Shdr
      connection: !ref shdrConnection
      subscribe:
        key: raw
        type: sample

  xact:
    type: Cybus::Endpoint
    properties:
      protocol: Shdr
      connection: !ref shdrConnection
      subscribe:
        key: Xact
        type: sample

  temperature:
    type: Cybus::Endpoint
    properties:
      protocol: Shdr
      connection: !ref shdrConnection
      subscribe:
        key: temp_cond
        type: condition

  mapping:
    type: Cybus::Mapping
    properties:
      mappings:
        - subscribe:
            endpoint: !ref raw
          publish:
            topic: !sub '${MQTT_TOPIC_PREFIX}/raw'
        - subscribe:
            endpoint: !ref xact
          publish:
            topic: !sub '${MQTT_TOPIC_PREFIX}/xAct'
        - subscribe:
            endpoint: !ref temperature
          publish:
            topic: !sub '${MQTT_TOPIC_PREFIX}/tempCondition'
```

{% endcode %}

* [Connection Properties](/2-6-1/connectors/shop-floor-connectors/shdr/shdrconnection.md)
* [Endpoint Properties](/2-6-1/connectors/shop-floor-connectors/shdr/shdrendpoint.md)

## Output Format

If data is read from SHDR the output will be provided as JSON object

type: sample, event

{% code lineNumbers="true" %}

```yaml
{ 'timestamp': '<msSinceEpoch>', 'value': '<value>' }
```

{% endcode %}

type: condition

{% code lineNumbers="true" %}

```yaml
{
  'timestamp': '<msSinceEpoch>',
  'value': { 'level': '<level>', 'nativeCode': '<nativeCode>', 'nativeSeverity': '<nativeSeverity>', 'qualifier': '<qualifier>', 'text': '<text>' },
}
```

{% endcode %}

type: message

{% code lineNumbers="true" %}

```yaml
{ 'timestamp': '<msSinceEpoch>', 'value': { 'nativeCode': '<nativeCode>', 'text': '<text>' } }
```

{% endcode %}

type: alarm

{% code lineNumbers="true" %}

```yaml
{ 'timestamp': '<msSinceEpoch>', 'value': { 'code': '<code>', 'nativeCode': '<nativeCode>', 'severity': '<severity>', 'state': '<state>' } }
```

{% endcode %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.cybus.io/2-6-1/connectors/shop-floor-connectors/shdr.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.