> 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-4-2/guides/machine-connectivity/robots-sensors-shop-floor-devices/connecting-werma-signal-towers.md). # Connecting WERMA Signal Towers This guide shows you how to read machine states from WERMA signal towers with the Connectware [Werma WIN Ethernet connector](/2-4-2/connectors/shop-floor-connectors/werma-win-ethernet.md) and map them into an ISA-95 style MQTT topic hierarchy. A signal tower already shows the state of its machine on the shop floor, and the Werma WIN system makes exactly this state available for digital processing: a wireless transmitter on each tower reports the light states to a central Ethernet master. Because the state is taken from the tower itself, you get machine monitoring without touching the PLC or the machine control. The collected tier states are the typical input for andon boards, machine monitoring, and Overall Equipment Effectiveness (OEE) dashboards. In more detail, the following topics are covered: * Understanding how the Werma WIN system provides machine states * Finding the MAC addresses of the transmitters * Creating the [service commissioning file](/2-4-2/data-flows/service-commissioning-files.md) * Mapping tower and tier states into an ISA-95 style MQTT topic hierarchy * Turning the red tier into a machine-stop event with the [Rule Engine](/2-4-2/data-flows/rule-engine/data-processing-rules.md) * Verifying data in the [Data Explorer](/2-4-2/monitoring/data-explorer.md) A complete example file is available at the end of this guide. ## Prerequisites To follow this guide, you will need the following: * A running instance of Cybus Connectware. * A configured Werma WIN system: each signal tower is equipped with a WIN slave device (a wireless transmitter), the transmitters are associated with a Werma WIN Ethernet master, and the Ethernet port of the master is reachable from Connectware. The association between the Ethernet master and the transmitters is configured with the Windows-based Werma WIN software that is shipped with the hardware. * The IP address, port, and password of the Werma WIN Ethernet master. * Access to the [Admin UI](/2-4-2/access/admin-ui.md) with sufficient [user permissions](/2-4-2/access/user-management.md). * Basic knowledge of MQTT and the Connectware [services](/2-4-2/data-flows/services.md) concept (for example, [service commissioning files](/2-4-2/data-flows/service-commissioning-files.md), [connections](/2-4-2/data-flows/service-commissioning-files/resources/cybus-connection.md), and [endpoints](/2-4-2/data-flows/service-commissioning-files/resources/cybus-endpoint.md)). ## How the Werma WIN System Provides Machine States The Werma WIN system consists of two kinds of devices. Each signal tower carries a WIN slave device, a wireless transmitter that monitors the switching state of the tower's tiers. The Werma WIN Ethernet master acts as the access point for this wireless network: it manages access to all associated transmitters, aggregates their data, and forwards it over Ethernet. Connectware connects to the Ethernet master with the `Werma` protocol and maps the proprietary Werma WIN protocol into MQTT/JSON. For the full system description, see the [Werma WIN Ethernet connector reference](/2-4-2/connectors/shop-floor-connectors/werma-win-ethernet.md). Every transmitter provides the following data points: * **Tiers** (`t1`, `t2`, `t3`, `t4`): the state of up to four digital switches, typically one per light tier of the tower. Each tier is `on`, `off`, or `blink`. * **RSSI**: the signal strength of the wireless connection between the transmitter and the Ethernet master. The WIN system sends state updates at fixed time intervals and whenever the state of any tier changes. You do not configure a polling interval; Connectware receives the updates as the WIN system sends them. Which color a tier corresponds to depends on how the signal tower is assembled. In this guide, tier 1 (`t1`) is the red light. Check the tower assembly of your machines and adjust the tier selection accordingly. {% hint style="info" %} A Werma WIN Ethernet master allows only one concurrent connection. If other applications, such as the Werma WIN Shop Floor Manager, need the data alongside Connectware, use the Connectware Werma Proxy Service to distribute the data to multiple applications simultaneously. See the [Werma WIN Ethernet connector reference](/2-4-2/connectors/shop-floor-connectors/werma-win-ethernet.md#werma-win-shop-floor-manager). {% endhint %} ## Finding the Transmitter MAC Addresses Each transmitter is identified by its unique MAC address, for example `00BCDD`. You can discover the MAC addresses of the associated transmitters in two ways: * Inspect the Connectware logs after the connection to the Ethernet master is established. * Use the Windows-based Werma WIN configuration software. Write down which MAC address belongs to which machine. You will need one MAC address per signal tower in the service commissioning file. ## Writing the Service Commissioning File The service commissioning file contains all connection and mapping details. Do not worry about copying the snippets together into one file, the complete example file is available at the end of this guide. The example connects two signal towers, one on a milling machine and one on a lathe. ### Description and Metadata These sections contain general information about the service commissioning file. Only the metadata name is required. {% code lineNumbers="true" %} ```yaml description: > Service commissioning file that reads machine states from WERMA signal towers with the Werma WIN Ethernet connector and maps them into an ISA-95 style MQTT topic hierarchy (Example) metadata: name: WERMA Signal Towers Example provider: cybus homepage: https://www.cybus.io version: 1.0.0 ``` {% endcode %} ### Parameters and Definitions We define the network address and the password of the Ethernet master as parameters, so you can set them when you install the service. The password has the factory default `b1b0`. The MAC addresses of the transmitters are parameters as well, so you can reuse the service for other machines. The MQTT topics in this guide follow an ISA-95 style equipment hierarchy (`///`). We define the prefix once in the `definitions` section and reuse it in every mapping with `!sub`. {% code lineNumbers="true" %} ```yaml parameters: wermaHost: description: Hostname or IP address of the Werma WIN Ethernet master type: string default: 192.168.1.100 wermaPort: description: Port of the Werma WIN Ethernet master type: integer default: 15200 wermaPassword: description: Password of the Werma WIN Ethernet master type: string default: b1b0 millingMac: description: MAC address of the transmitter on the milling machine tower type: string default: 00BCDD latheMac: description: MAC address of the transmitter on the lathe tower type: string default: 00BCDE definitions: MQTT_TOPIC_PREFIX: enterprise/hamburg/machining/line-1 ``` {% endcode %} ### Cybus::Connection The connection resource establishes the connection to the Ethernet port of the Werma WIN Ethernet master. The optional `connectionStrategy` controls the retry behavior if a connection attempt fails. For all connection properties, see [Werma WIN Ethernet Connection Properties](/2-4-2/connectors/shop-floor-connectors/werma-win-ethernet/wermaconnection.md). {% code lineNumbers="true" %} ```yaml resources: wermaConnection: type: Cybus::Connection properties: protocol: Werma targetState: connected connection: host: !ref wermaHost port: !ref wermaPort password: !ref wermaPassword connectionStrategy: initialDelay: 1000 maxDelay: 10000 incrementFactor: 2 ``` {% endcode %} ### Cybus::Endpoint Each endpoint subscribes to one transmitter, identified by its MAC address. The `field` property selects which data point of the transmitter the endpoint carries: | Field | Data | | ---------------------- | ------------------------------------------------ | | `t1`, `t2`, `t3`, `t4` | The state of one tier: `on`, `off`, or `blink` | | `all` | All tier states and the RSSI value in one object | | `rssi` | The signal strength of the wireless connection | | `raw` | Raw data as received from the Ethernet master | For all endpoint properties, see [Werma WIN Ethernet Endpoint Properties](/2-4-2/connectors/shop-floor-connectors/werma-win-ethernet/wermaendpoint.md). This guide uses `all` for the complete tower state of each machine, `t1` for the red tier of the milling machine, and `rssi` to monitor the wireless link quality: {% code lineNumbers="true" %} ```yaml millingTowerState: type: Cybus::Endpoint properties: protocol: Werma connection: !ref wermaConnection subscribe: mac: !ref millingMac field: all millingRedTier: type: Cybus::Endpoint properties: protocol: Werma connection: !ref wermaConnection subscribe: mac: !ref millingMac field: t1 millingRssi: type: Cybus::Endpoint properties: protocol: Werma connection: !ref wermaConnection subscribe: mac: !ref millingMac field: rssi latheTowerState: type: Cybus::Endpoint properties: protocol: Werma connection: !ref wermaConnection subscribe: mac: !ref latheMac field: all ``` {% endcode %} ### Cybus::Mapping The [mapping](/2-4-2/data-flows/service-commissioning-files/resources/cybus-mapping.md) publishes each endpoint on a topic of the ISA-95 hierarchy. {% code lineNumbers="true" %} ```yaml mapping: type: Cybus::Mapping properties: mappings: - subscribe: endpoint: !ref millingTowerState publish: topic: !sub '${MQTT_TOPIC_PREFIX}/milling-01/tower/state' - subscribe: endpoint: !ref millingRedTier publish: topic: !sub '${MQTT_TOPIC_PREFIX}/milling-01/tower/red' - subscribe: endpoint: !ref millingRssi publish: topic: !sub '${MQTT_TOPIC_PREFIX}/milling-01/tower/rssi' - subscribe: endpoint: !ref latheTowerState publish: topic: !sub '${MQTT_TOPIC_PREFIX}/lathe-01/tower/state' ``` {% endcode %} With this mapping, the complete tower state of the milling machine is published on the topic `enterprise/hamburg/machining/line-1/milling-01/tower/state`, and every other endpoint follows the same pattern. ## Turning the Red Tier into a Machine-Stop Event The topics so far carry states. Downstream consumers such as andon boards or alerting systems often want events instead: one message at the moment a machine stops. You can derive this event from the red tier with two [data processing rules](/2-4-2/data-flows/rule-engine/data-processing-rules.md) in an additional mapping: * The [`cov` rule](/2-4-2/data-flows/rule-engine/data-processing-rules.md#cov) (change of value) only forwards a message when the tier state differs from the previous one. This suppresses the periodic updates that the WIN system sends while the state is unchanged. * The [`filter` rule](/2-4-2/data-flows/rule-engine/data-processing-rules.md#filter) discards every message whose JSONata expression evaluates to a falsy value. The expression `value = 'on'` only lets messages pass in which the red tier is switched on. {% code lineNumbers="true" %} ```yaml - subscribe: endpoint: !ref millingRedTier publish: topic: !sub '${MQTT_TOPIC_PREFIX}/milling-01/events/machine-stop' rules: - cov: key: value - filter: expression: value = 'on' ``` {% endcode %} The combination publishes exactly one message on `enterprise/hamburg/machining/line-1/milling-01/events/machine-stop` at the moment the red light switches on. If a blinking red light also counts as a stop on your shop floor, extend the expression to `value = 'on' or value = 'blink'`. ## Installing the Service Commissioning File 1. Install the service commissioning file. See [Installing Services](/2-4-2/data-flows/services/managing/installing.md). 2. Enable the service. See [Enabling Services](/2-4-2/data-flows/services/managing/enabling.md). **Result:** The service is enabled. Connectware connects to the Werma WIN Ethernet master and starts receiving state updates from the configured transmitters. ## Verifying the Data Open the [Data Explorer](/2-4-2/monitoring/data-explorer.md) and subscribe to `enterprise/hamburg/machining/line-1/#`. The `tower/state` topics carry a JSON object with all tier states and the RSSI value: {% code lineNumbers="true" %} ```json { "timestamp": 1784194200354, "value": { "t1": "off", "t2": "off", "t3": "on", "t4": "off", "rssi": 63 } } ``` {% endcode %} The single-tier topic `tower/red` carries the state of the red tier alone: {% code lineNumbers="true" %} ```json { "timestamp": 1784194200354, "value": "off" } ``` {% endcode %} A few plausibility checks for the first readings: * The tier states on the `tower/state` topics match the lights you see on the towers. * When a tier changes on the machine, the update appears on the topic within a few seconds. * The `tower/rssi` value is a number and stays in a similar range over time. A sudden drop indicates a problem with the wireless link between the transmitter and the Ethernet master. * The `events/machine-stop` topic stays silent until the red light switches on, and then carries exactly one message. If the connection does not reach the **Connected** state, verify that the IP address, port, and password match the Ethernet master and that the port is reachable from Connectware. Also make sure that no other application is connected to the Ethernet master, for example the Werma WIN configuration software or the Werma WIN Shop Floor Manager, because the Ethernet master allows only one concurrent connection. If the connection is established but a tower publishes no data, check the MAC address of its transmitter in the Connectware logs or in the Werma WIN configuration software, and verify that the transmitter is associated with the Ethernet master you are connected to. ## Service Commissioning File Example {% file src="/files/WXCHakxcOjBmTiP4ae4E" %} {% code title="werma-signal-towers-example.yml" lineNumbers="true" expandable="true" %} ```yaml --- # ---------------------------------------------------------------------------- # Service Commissioning File # ---------------------------------------------------------------------------- # Copyright: Cybus GmbH # Contact: support@cybus.io # ---------------------------------------------------------------------------- # Connecting WERMA Signal Towers (Example) # ---------------------------------------------------------------------------- description: > Service commissioning file that reads machine states from WERMA signal towers with the Werma WIN Ethernet connector and maps them into an ISA-95 style MQTT topic hierarchy (Example) metadata: name: WERMA Signal Towers Example provider: cybus homepage: https://www.cybus.io version: 1.0.0 parameters: wermaHost: description: Hostname or IP address of the Werma WIN Ethernet master type: string default: 192.168.1.100 wermaPort: description: Port of the Werma WIN Ethernet master type: integer default: 15200 wermaPassword: description: Password of the Werma WIN Ethernet master type: string default: b1b0 millingMac: description: MAC address of the transmitter on the milling machine tower type: string default: 00BCDD latheMac: description: MAC address of the transmitter on the lathe tower type: string default: 00BCDE definitions: # ISA-95 style topic prefix: /// MQTT_TOPIC_PREFIX: enterprise/hamburg/machining/line-1 resources: # Connection to the Werma WIN Ethernet master wermaConnection: type: Cybus::Connection properties: protocol: Werma targetState: connected connection: host: !ref wermaHost port: !ref wermaPort password: !ref wermaPassword connectionStrategy: initialDelay: 1000 maxDelay: 10000 incrementFactor: 2 # All data points of the milling machine tower: tiers t1-t4 and RSSI millingTowerState: type: Cybus::Endpoint properties: protocol: Werma connection: !ref wermaConnection subscribe: mac: !ref millingMac field: all # Red tier of the milling machine tower (tier 1 in this example) millingRedTier: type: Cybus::Endpoint properties: protocol: Werma connection: !ref wermaConnection subscribe: mac: !ref millingMac field: t1 # Wireless signal strength of the milling machine transmitter millingRssi: type: Cybus::Endpoint properties: protocol: Werma connection: !ref wermaConnection subscribe: mac: !ref millingMac field: rssi # All data points of the lathe tower latheTowerState: type: Cybus::Endpoint properties: protocol: Werma connection: !ref wermaConnection subscribe: mac: !ref latheMac field: all mapping: type: Cybus::Mapping properties: mappings: - subscribe: endpoint: !ref millingTowerState publish: topic: !sub '${MQTT_TOPIC_PREFIX}/milling-01/tower/state' - subscribe: endpoint: !ref millingRedTier publish: topic: !sub '${MQTT_TOPIC_PREFIX}/milling-01/tower/red' - subscribe: endpoint: !ref millingRssi publish: topic: !sub '${MQTT_TOPIC_PREFIX}/milling-01/tower/rssi' - subscribe: endpoint: !ref latheTowerState publish: topic: !sub '${MQTT_TOPIC_PREFIX}/lathe-01/tower/state' # Machine-stop event: only forward when the red tier switches to 'on' - subscribe: endpoint: !ref millingRedTier publish: topic: !sub '${MQTT_TOPIC_PREFIX}/milling-01/events/machine-stop' rules: - cov: key: value - filter: expression: value = 'on' ``` {% endcode %} {% hint style="info" %} Disclaimer: WERMA and WERMA WIN are trademarks of WERMA Signaltechnik GmbH + Co. KG. {% endhint %} --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.cybus.io/2-4-2/guides/machine-connectivity/robots-sensors-shop-floor-devices/connecting-werma-signal-towers.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.