Arduino Opta Ethernet MQTT Home Assistant: Relays, Inputs, Discovery and Reliable Control

The Arduino Opta is an excellent Home Assistant controller when you want something more industrial than a Wi-Fi development board.

Every Opta variant includes:

This means even Opta Lite can become a wired MQTT node for Home Assistant without using Wi-Fi.

A practical architecture is:

Why Use Ethernet Instead of Wi-Fi?

For fixed automation equipment, wired Ethernet normally gives:

• more predictable connectivity;
• less RF interference;
• easier troubleshooting;
• simpler network segmentation;
• no Wi-Fi credential dependency;
• more stable operation in metal control cabinets.

All Opta models include Ethernet, so this guide works with:

Hardware Architecture

The Opta communicates with an MQTT broker over its onboard:

Home Assistant then interacts with the broker rather than connecting directly to the PLC.

Typical topology:

MQTT Broker

Home Assistant needs access to an MQTT broker.

A common installation uses Mosquitto, but any broker compatible with the Home Assistant MQTT integration can work.

The broker should normally require:

• username/password authentication;
• network access control;
• appropriate firewall rules;
• TLS where traffic leaves a trusted local network.

Suggested Topic Structure

Do not create random topic names for every variable.

A simple hierarchy makes the system easier to maintain:

The distinction between:

is important.

Command Topic vs State Topic

Home Assistant sends a requested change to:

The Opta then operates the physical relay and publishes the resulting state to:

This gives Home Assistant confirmation from the device instead of assuming the command succeeded.

Avoid Optimistic Relay Control

Home Assistant can operate MQTT switches without a state topic, but then it works optimistically.

For an industrial controller, a better pattern is:

This keeps the user interface aligned with the controller.

Required Arduino Libraries

The main libraries are:

The Opta Mbed core includes an Ethernet library designed for its onboard PHY.

Install ArduinoMqttClient through the Arduino Library Manager if it is not already installed.

Starting Ethernet with DHCP

On Opta, the simplest Ethernet initialisation is:

The Opta core can use the board’s factory Ethernet information, so you do not need to invent the old shield-style MAC address manually.

Check the Ethernet Link

During commissioning, check:

before blaming MQTT.

If there is no link:

• check the RJ45 cable;
• check the switch port;
• check VLAN configuration;
• check that the Opta is powered from its normal 12-24 V supply.

Static IP Address

For fixed automation equipment, a static lease in the DHCP server is often preferable to hard-coding network settings in firmware.

If you do need a static address in the sketch, the Opta Ethernet API supports:

Create the MQTT Client

MQTT Authentication

Configure a dedicated MQTT account for the Opta:

Do not reuse the Home Assistant administrator password.

Availability Topic

A useful availability topic is:

with:

payloads.

MQTT Last Will and Testament

The MQTT broker can automatically publish:

if the Opta disappears unexpectedly.

Configure the Last Will before connecting:

The:

argument retains the offline state at the broker.

Publish Online After Connection

After MQTT connects successfully:

Home Assistant can now show entities as unavailable when the Opta loses its broker connection.

MQTT Connection Function

Always Call mqttClient.poll()

The ArduinoMqttClient library expects:

to run regularly.

This processes incoming packets and MQTT keep-alive traffic.

Do not put long blocking delays in the main loop.

Relay Pin Mapping

On Opta:

The relays are physical normally-open electromechanical contacts.

Set Up Relay Outputs

Starting in the OFF state is usually the safest default unless the machine risk assessment requires different behaviour.

Subscribe to Relay Commands

Process the Command

Publish Confirmed Relay State

The state is retained so Home Assistant immediately knows the last reported relay state after reconnecting.

Should Command Topics Be Retained?

For real actuator commands, usually:

A retained:

command could be replayed when the Opta reconnects after a restart.

That may be undesirable or unsafe.

A safer pattern is:

Publish Input States

Opta inputs map as:

For a digital input:

Do Not Flood MQTT

A PLC loop can execute thousands of times per second.

Do not publish a message every loop iteration.

Instead publish:

• when a digital state changes;
• when an analogue value changes significantly;
• at a sensible periodic heartbeat;
• when Home Assistant restarts and asks for discovery/state again.

Publish on Change

Publishing Analogue Inputs

Opta I1-I8 can also be used for:

with user-configurable ADC resolution.

A Home Assistant topic might be:

with payload:

Filter Analogue Values Before Publishing

A noisy analogue signal may vary by a few ADC counts continuously.

Use:

• moving average;
• deadband;
• minimum change threshold;
• maximum publish interval.

For example:

Home Assistant Manual MQTT Switch

A relay can be configured manually in Home Assistant:

Why state_topic Matters

When a:

is configured, Home Assistant waits for the Opta to publish the actual state instead of simply assuming a command succeeded.

Home Assistant MQTT Discovery

Home Assistant supports automatic MQTT discovery.

The default discovery prefix is:

A single switch can be announced on:

Example Discovery Payload

Publish the discovery message with the:

flag so Home Assistant receives it after restarting.

ArduinoMqttClient Discovery Message

Increase MQTT Payload Buffer If Required

Discovery JSON can become large when you define many entities.

ArduinoMqttClient allows the transmit payload size to be increased:

Do this before publishing large discovery payloads.

Home Assistant Device Discovery

Current Home Assistant versions also support:

where several components are included in one device discovery message.

For a device such as Opta with:

• eight inputs;
• four relays;
• analogue values;
• availability;

device discovery can reduce the number of separate discovery messages.

Retained Discovery vs Home Assistant Birth Message

There are two common approaches.

Simple embedded approach:

so the broker replays them whenever Home Assistant subscribes.

More dynamic approach:

and republish discovery when Home Assistant publishes:

after startup.

Home Assistant Status Topic

By default Home Assistant publishes its own birth/status messages to:

This can be useful for causing the Opta to:

• republish discovery;
• republish relay states;
• republish current input states.

Reconnect Logic

Networks fail.

The sketch must recover without requiring a PLC restart.

Do Not Reconnect in a Tight Loop

If the broker is offline, an immediate reconnect loop can monopolise the CPU and flood the network.

Use a retry interval such as:

or exponential back-off for longer outages.

Complete Main Loop Pattern

MQTT should be a communications layer around the controller, not the controller’s only source of logic.

Local Control Should Continue Without Home Assistant

For serious automation, design the Opta so that:

Critical logic should remain local on the Opta.

Home Assistant should typically provide:

• supervision;
• setpoints;
• status;
• non-critical commands;
• logging;
• notifications.

Home Assistant Is Not a Safety PLC

Do not use MQTT/Home Assistant as the sole safety layer for:

• emergency stops;
• machine guarding;
• over-temperature shutdown;
• over-pressure protection;
• personnel safety;
• critical motor interlocks.

Those functions require appropriate local hardware and safety architecture.

Relay Commands Should Be Validated Locally

Instead of:

a better industrial pattern may be:

Retained State Needs Care

Retaining:

can be useful because Home Assistant receives a state immediately after reconnecting.

But a retained message represents the:

not proof that the physical system is still in that state now.

Republish Physical State After Restart

When the Opta boots:

Do not blindly restore a potentially dangerous actuator from an old retained command.

MQTT QoS

Typical choices are:

QoS alone does not create application-level safety or exactly-once physical operation.

MQTT Client IDs Must Be Unique

If two Opta controllers both connect using:

as the MQTT client ID, the broker may repeatedly disconnect one when the other connects.

Use unique IDs such as:

MQTT Credentials Per Controller

For multiple Optas, use separate credentials where practical:

This allows broker ACL rules such as:

Network Segmentation

In an industrial installation, consider placing automation devices on a dedicated:

with firewall rules that allow only required traffic to:

• MQTT broker;
• Home Assistant;
• DNS;
• NTP;
• management stations.

MQTT Broker Outside the LAN

If the broker is accessed over an untrusted network:

Use TLS, VPN or another secure network architecture.

Home Assistant Sensor Example

A manually configured analogue sensor could look like:

Home Assistant Binary Sensor Example

Recommended Topic Layout for a Full Opta

Common Mistake 1: Publishing Every Loop

This can create thousands of MQTT messages per second.

Publish on change and use sensible periodic updates.

Common Mistake 2: Retaining Relay Commands

A stale retained ON command may be replayed after reconnect.

Retain state, not actuator requests, unless the application has been deliberately designed around retained commands.

Common Mistake 3: No Availability Topic

Without availability, Home Assistant may continue displaying the last state even when the Opta is physically offline.

Common Mistake 4: No State Confirmation

A Home Assistant switch should preferably have both:

so it is not operating purely optimistically.

Common Mistake 5: Blocking delay()

Long delays interfere with:

• MQTT keep-alives;
• incoming commands;
• input scanning;
• reconnect logic;
• local PLC tasks.

Use millis()-based timing instead.

Common Mistake 6: Making Home Assistant the Interlock

Do not place a safety condition only in a Home Assistant automation.

The Opta should enforce important permissives locally.

Common Mistake 7: No Reconnect State Republish

After reconnecting:

so Home Assistant and the PLC become synchronised again.

Quick Architecture Reference

Final Thoughts

Opta and Home Assistant work particularly well together when the roles are kept clear.

Opta should remain responsible for:

Home Assistant should provide:

MQTT becomes the clean boundary between the two.

Using Ethernet, a confirmed state topic, Last Will availability and sensible reconnect handling produces a substantially more robust integration than simply publishing relay commands over Wi-Fi.

For the underlying terminal mapping, see our Arduino Opta pinout and I/O guide. For serial field devices on Opta RS485/WiFi, see our Arduino Opta Modbus RS485 guide.