Zigbee2MQTTBridge 2.8.2

The GitHub record inside the bundle now uses the standard spelling.

The plugin bundle carries a small record of where its source lives on GitHub. Ours spelt the two field names its own way, while the plugins Indigo Domotics and the community publish spell them GithubUser and GithubRepo. It now matches them. Nothing else changed.

Install: download Zigbee2MQTTBridge.indigoPlugin.zip, unzip it, and double-click Zigbee2MQTTBridge.indigoPlugin — Indigo installs it. An existing install picks the change up on the next plugin restart.

v2.8.1 — the settings dialogs fit their own window

The settings dialogs were stretched far wider than their own window, so the help text beside each setting was cut off mid-sentence.

The short help that can be attached to a setting is drawn on a single line and never wraps, so the longest one in the dialog decides how wide every row is. One here ran to 781 characters, which stretched the dialog well past a window that cannot be widened past a fixed maximum — so every line of help was clipped.

All five long ones have moved into ordinary description paragraphs, which do wrap. Two new checks fail the build if any help text or setting label grows long enough to do it again. No setting or behaviour changed.

Installation

1. Download Zigbee2MQTTBridge.indigoPlugin.zip below.
2. Unzip it — you will get Zigbee2MQTTBridge.indigoPlugin.
3. Double-click it — Indigo will install it automatically.

v2.8.0 — command echoes moved to the plugin's own log

About 82 lines a day of sent "Hall Lamp" set brightness to 40% and its kin were filling the shared event log, growing with every light and every switch. They now go to this plugin's own log — which is where you look when a light did not respond anyway — and a new tick box puts them back.

Failures still go to the event log. A command that never reached the Zigbee network is exactly what you need telling about. So do devices joining or leaving, and the bridge going offline.

816 -> 821 tests.

v2.7.2 — the stored IEEE follows the friendly name

A device made by duplicating another in the Indigo client carries the original's IEEE address, and that field is read-only in the dialog, so nobody could put it right. It worked, because routing follows the friendly name — until the rename detector, which keys on the IEEE, read the clash as a rename.

• The stored IEEE now follows the friendly name zigbee2mqtt reports, on every device-list refresh, and the log says so.
• The rename detector will not move a device onto a name another Indigo device already owns. It warns once, naming both.
• A device first seen before zigbee2mqtt had interviewed it is created on the refresh that brings its definition, rather than never.

Install: download Zigbee2MQTTBridge.indigoPlugin.zip, unzip, double-click the bundle.

v2.7.1 — a readable completion message

The message announcing a finished firmware update was printing zigbee2mqtt's raw reply into the middle of the sentence:

now on version {'date_code': '20260514', 'file_version': 16788992, 'software_build_id': '1.163.1'}

It now reads:

now running 1.163.1 (build 16788992, 14 May 2026)

Two separate signals tell the plugin an update has ended — the bridge's reply, and the device coming back — and they arrive seconds apart. It no longer announces the same update twice.

v2.7.0 — be told when a firmware update finishes

There were triggers for an update becoming available, and none at all for it ending — so you had to keep checking whether it had worked.

There are now Firmware Update Finished and Firmware Update Failed trigger events. Hook one to a notification and the device tells you itself.

Worth knowing what "finished" means here. Progress reaching 100% only means the file has transferred; the device then writes it and restarts, and it is coming back that actually counts. The trigger waits for that, so when it fires the device really is running the new firmware.

v2.6.0 — install a firmware update in two clicks

Installing a waiting firmware update meant building an Action Group to press a button once. That was the wrong shape for a one-off job.

There is now Plugins → Zigbee2MQTT Bridge → Update Device Firmware..., which lists only the devices that actually have an update waiting, showing the version each is on and the version it would move to. Pick one and it starts.

The action is still there for use in a trigger or schedule, and both routes go through exactly the same safety checks — the menu is not a shortcut past them.

v2.5.1 — quieter firmware checks

Asking a houseful of battery sensors about their firmware means most of them are asleep and will not answer. That is normal, not a fault, but it was being reported as an error — one routine check produced eight red lines.

Those ordinary outcomes now appear as plain information. A genuine failure still shows as an error.

The log also referred to a device called "?" whenever zigbee2mqtt's reply did not identify one. It now simply says what happened, since the message already names the device.

v2.5.0 — split a sensor's extra readings into their own devices

A presence sensor that also measures temperature, humidity and light puts all of it into a single Indigo device, where the extra readings sit as plain states. No sensor type, nothing HomeKit can see, and nowhere obvious to put them on a control page.

Open such a device's settings and you will now find a Separate Devices section listing what else it measures. Tick one and that reading gets its own Indigo device, grouped with the original, appearing as a proper temperature or humidity sensor with its value where Indigo expects it.

The original device is left completely alone — same device, same id, same states — so every trigger, script and control page pointing at it carries on working exactly as before. That is what makes this safe to offer.

Change your mind and unticking the box never deletes anything. The extra device is renamed and set aside in case something points at it, and you remove it yourself once you are sure.

Only readings the device actually reports are offered. Nothing happens until you tick a box.

v2.4.2 — housekeeping

Two small things.

Settings you leave blank in a device's dialog are no longer stored, so its properties show only the handful you actually chose rather than every setting the device offers.

And the startup message about a couple of devices showing an older state in the device list is now an ordinary note instead of a warning. It is cosmetic, the only cure would be deleting and recreating the device, and a warning you can never act on simply teaches you to ignore warnings — which is a poor habit for the moment a real one appears.

Nothing to do on upgrade.