realtimelogic/opc-ua-examples

1. This repository is a set of self-contained OPC UA example deployments for Real Time Logic’s OPC-UA stack, intended to run on the Mako Server runtime. The architectural unit is usually a single example directory started with mako -l::Directory-Name.

2. The repo is split into three primary domains: server examples under servers/, client examples under client/, and embedded/device examples under esp32/. That separation is the main architectural boundary: each domain demonstrates a different role in the OPC UA ecosystem.

3. The server-side examples are mostly Lua-based OPC UA servers. Files such as servers/*/opcua_server.lua and servers/*/opcua_server.lsp define the server behavior, while .preload markers indicate Mako-managed startup hooks and module loading. These examples cover data exposure, node creation, browsing, reading/writing, and server configuration.

4. Several server examples include an embedded web UI. In those cases, index.html, ua_server.js, and vue.js sit beside the OPC UA server logic, showing a two-tier model: browser UI on top, OPC UA endpoint underneath. The embed_web_server and server_http / server_basic128rsa15 examples illustrate this integration.

5. Security is a distinct architectural concern in the server examples. The presence of .pem and .key files, along with example names like basic128rsa15, indicates secured OPC UA endpoints using certificates and encrypted channels. There is also a server_config example that likely focuses on runtime configuration rather than application logic.

6. The client side demonstrates OPC UA consumers rather than providers. client/auth_username and client/auth_x509 show different authentication paths against OPC UA servers, while client/start contains the entry script for a browser-synchronized or interactive client flow. The inclusion of certificates in auth_x509 reinforces the security/authentication boundary.

7. The ESP32 examples represent the hardware/device edge. esp32/1wire contains Lua modules for 1-wire sensor access, DS18B20 temperature reading, MQTT publishing, and an OPC UA server bridge. This is the clearest end-to-end data pipeline in the repo: physical sensor → Lua driver → MQTT publish / OPC UA exposure.

8. esp32/ignition is a separate embedded control example built around an LED and button. Its assets and opc-led-button-server.xlua suggest a hardware control loop where the microcontroller exposes or reacts to OPC UA variables/events tied to local GPIO state.

9. The data flow patterns are intentionally simple and repetitive across examples: device state or application variables are made available through OPC UA nodes; clients browse/read/write those nodes; optional web UIs render or control the same state through JavaScript calling into the server layer. This makes the repo useful for understanding OPC UA from both producer and consumer perspectives.

10. The repo relies on the Mako Server plugin model rather than a standalone application framework. That runtime choice matters architecturally because each example is packaged as a deployable directory with startup hooks, static assets, Lua logic, and optional certificates all co-located.

11. At the root, index.lsp and local_server.lua act as top-level helpers or entry points for local/demo execution. They are not the main application boundary so much as convenience scaffolding around the example directories.

12. For diagramming, the key boxes are: Mako Server runtime, OPC UA server examples, OPC UA client examples, browser/web UI examples, ESP32 device examples, and external dependencies such as certificates, MQTT, and physical sensors/buttons. The important arrows are server/client OPC UA sessions, browser-to-server HTTP/JS interaction, and hardware-to-server data acquisition/control.