Wizata Edge is an extension of the Wizata cloud architecture installed on your premises. The cloud platform configures and deploys it, and it keeps operating when the internet connection drops.

Edge covers two roles:

• Connect data sources to the platform: OPC-UA, AMQP, MQTT, Modbus, S7 and others.
• Run pipelines locally, for closed-loop automation that does not need high-frequency computation.

📘

Edge components require a professional license, and running pipelines on one is an add-on.

Overview

The Edge is composed of these modules:

• Message Client handles the live data flow:
  • consumers subscribe to and consume messages from your data sources.
  • triggers detect when a pipeline must run and queue it.
  • writers write data to assets, to the cloud or to the local time-series database.
• Time-Series DB stores telemetry locally, mainly to buffer what pipelines need.
• AI/ML Pipeline Engine runs the pipelines deployed to the device.
• Config Sync fetches the device's configuration from the cloud and signals the other modules to reconfigure.

Requirements

Runtime and operating system

Wizata deploys its modules to the device with Azure IoT Edge, a runtime for deploying, running and monitoring containerised Linux workloads.

Other systems Microsoft supports, such as Red Hat Enterprise Linux or IoT Edge for Linux on Windows (EFLOW), are not validated by Wizata. Contact Wizata before installing on one. See Microsoft's supported platforms and releases.

Hardware and storage

We recommend the following specifications for the machine, virtual or physical:

• 2 vCPU and 8 GB RAM.
• Two disks:
  • 20 GB for the operating system (LVM, Ubuntu defaults are fine).
  • 80 GB mounted as /var/lib/docker for the containers and their data. We recommend a dedicated LVM volume group so the disk can grow. If you format it as XFS, use ftype=1, which the overlay2 storage driver requires (see Docker's OverlayFS prerequisites).
• One network interface, plus one per additional network when data sources sit in a DMZ or on separate networks.

The device can keep up to 31 days of logs locally and buffers telemetry in its time-series database, so disk use grows with the number of data points and their frequency.

Moby sets no size limit on container logs by default. Configure a limit in /etc/docker/daemon.json before the modules are deployed, then restart the container engine:

{
  "log-driver": "local",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

Network

Prepare a connectivity list

Every firewall request for an edge device should rest on a connectivity list agreed between Wizata and your network team. Wizata supplies the cloud endpoints of your environment: the IoT hub, Event Hubs namespace, Wizata environment address and container registry. You supply your site's side: the device's source addresses (and NAT or proxy addresses), the data sources and their ports, the DNS and time servers, and the remote-access path.

The tables below list what a Wizata edge device connects to. Use them to build that list, with the exact names Wizata gives you in place of the placeholders.

Outbound connections

The device opens every cloud connection itself. No connection from the internet to the device is needed; allow the return traffic of the connections below.

Unless stated otherwise, ports are outbound TCP.

Some ports are not needed: 8883 (MQTT), because Wizata deployments use AMQP to IoT Hub; 5672 (plain AMQP), which IoT Edge does not support; and global.azure-devices-provisioning.net, because Wizata devices are registered with a connection string, not the Device Provisioning Service.

Only port 443 open? Not supported today. The Event Hubs connection requires 5671, and Wizata deployments do not switch the IoT Edge runtime to WebSockets.

Prefer exact host names to wildcards, and host names to IP addresses: Azure endpoints change IP addresses without notice. Web-filtering rules for HTTPS do not cover AMQP on 5671; the firewall must allow that port for the two Azure destinations as well.

The connections to your data sources (OPC-UA, MQTT, Modbus, S7, …) stay on your site. Their addresses and ports depend on your equipment; list them in the connectivity list.

Ports open on the device

The modules publish these ports on the device itself. None of them needs to be reachable from outside your site; restrict them to the networks that need them.

Proxies and TLS inspection

An outbound proxy is not supported. The Wizata modules connect directly, and AMQP on port 5671 cannot pass through an HTTP proxy.

Exclude the Wizata destinations from TLS inspection: <namespace>.servicebus.windows.net, <iot-hub>.azure-devices.net, the storage accounts, your onwizata.com environment and the log endpoint. The Wizata modules accept only certificates issued by public certificate authorities and reject a certificate re-signed by an inspecting firewall. Microsoft documents trusting an inspecting proxy for the IoT Edge runtime itself, but that does not extend to the Wizata modules.

Long-lived connections

The connections to IoT Hub and Event Hubs are kept open. A firewall or NAT device that silently drops an idle session makes the next send fail; the Message Client then reconnects and sends again. Keep idle timeouts on these paths as long as your security policy allows.

Verify connectivity

From the device, check the TLS path to each Azure destination on port 5671. Replace the placeholder with the name Wizata gave you:

HOST=<namespace>.servicebus.windows.net   # then <iot-hub>.azure-devices.net
openssl s_client -connect "$HOST:5671" -servername "$HOST" \
  -verify_hostname "$HOST" -verify_return_error </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer

• An issuer from Microsoft or DigiCert: the path is open and not inspected.
• An issuer from your organisation's certificate authority: the connection is being inspected. Exclude this host from inspection.
• A timeout or a reset: port 5671 is filtered on the way, or the traffic is being routed through a proxy. Check the firewall and routing logs before concluding.

This command checks the network path and the certificate, not authentication or message delivery. Never disable certificate validation to make it pass.

Once IoT Edge is installed, run sudo iotedge check --verbose. Only the AMQP (5671) and HTTPS (443) results apply; warnings for 8883 or for WebSockets on 443 can be ignored. Commissioning is complete when the device has pulled its images, its modules are running and its telemetry reaches the platform.

Installation and maintenance access

Wizata can install the operating system and configure the machine for you. In that case we need SSH access with a user that has sudo rights, preferably through your VPN.

Next Steps

Once your device is set up and the Azure IoT Edge agent runs on it, you are ready to register and set it up.