DocumentationWB-MDM3 known issues
ERRMODBUS001: Device replies to address 0xFD
Affected devices
WB-MDM3 with firmware earlier than 2.8.0.
Description
Fast Modbus devices can interfere with third-party devices on the same bus if those devices use special commands beginning with 0xFD.
Cause and details
Fast Modbus reserves 0xFD for special broadcast commands. If a third-party request starts with 0xFD but uses a command outside Fast Modbus, affected Wiren Board devices reply with MODBUS_ERR_ILLEGAL_FUNCTION, disrupting the other exchange. The bus driver incorrectly treats the packet as ordinary Modbus traffic.
Workaround
Avoid sharing a bus between affected Wiren Board and third-party devices.
Resolution
Fixed in firmware 2.8.0.
ERRMODBUS002: Incorrect response to discovery command 0x46
Affected devices
WB-MDM3 with firmware earlier than 2.7.1.
Description
Fast Modbus originally used function 0x60, later changed to 0x46 because 0x60 was in a reserved range. Backward compatibility retained both request codes, but the device always replied with 0x60. The fix replies with the same function used in the request: 0x46 or 0x60.
Remedy
Update firmware to 2.7.1.
Resolution
Fixed in firmware 2.7.1.
ERRMODBUS003: Unexpected behaviour when invalid values are written to some registers
Affected devices
WB-MDM3 with firmware earlier than 2.9.2.
Description
When values in the range [256 ... 65535] are written to some registers, the upper 8 bits are discarded and the firmware receives the value modulo 256. For example, writing 257 has the same effect as writing 1.
The device address register (128) is one affected register.
All registers work as expected within their documented ranges. The issue occurs when invalid values above 255 are written.
Remedy
Update firmware to 2.9.2.
Resolution
Fixed in firmware 2.9.2.
ERRMODBUS004: Incorrect bit-field replies
Affected devices
WB-MDM3 with firmware earlier than 2.7.1.
Description
Replies containing bit fields, including coil/discrete reads and event management, could contain incorrect high bits.
Remedy
Update firmware to 2.7.1.
Resolution
Fixed in firmware 2.7.1.
ERRMODBUS006: Responses to requests with incorrect parity
Affected devices
WB-MDM3 with firmware earlier than 2.9.1.
Description
The device replied to requests with incorrect parity instead of ignoring them.
Remedy
Update firmware to 2.9.1.
Resolution
Fixed in firmware 2.9.1.
ERRMODBUS007: Lost events when two devices transmit simultaneously on one bus
Affected devices
WB-MDM3 with firmware earlier than 2.12.0.
Description
When two devices on one bus have pending events simultaneously, one may transmit an incomplete event packet.
Cause and details
In Fast Modbus, the master requests events. All devices with pending events arbitrate; the winner replies, while the others wait for the next request.
A generated event waits for transmission. After the device places its frame on the bus, the event is marked sent. The master's next acknowledgement for that device removes the sent events from its queue. This is the normal acknowledgement mechanism.
The defect marked events as sent too early, on receipt of the event request, before arbitration finished. If the device won arbitration, operation was normal. If it lost, no packet was transmitted, but its events were already marked sent. A subsequent acknowledgement for that device also acknowledged these unsent events, removing them from the queue before they ever reached the master.
The web-interface value does not update and no MQTT message is published, although the device registers remain correct. The change notification is lost.
For example, if inputs on two relay modules on the same bus close simultaneously, one module may update correctly in the web interface while the other loses some events and still appears in its previous state despite physically switching.
Workaround
Temporarily disable event-based operation for affected registers by setting sporadic to false in the device template. The registers will then be polled at the configured interval.
Resolution
Fixed in firmware 2.12.0.
ERRMODBUS008: Unexpected behaviour with long request frames
Affected devices
WB-MDM3 with firmware earlier than 2.12.1.
Description
Receiving a frame longer than 265 bytes, the maximum Fast Modbus frame length, can freeze and reboot the device; settings may also be lost in some cases.
Cause and details
The receive algorithm did not handle oversized invalid requests, causing a buffer overflow and corruption of adjacent memory. The device freezes and the watchdog restarts it. Very large frames, above approximately 500 bytes, can also corrupt settings, causing a restart with default communication parameters: 9600 8N2, address 1.
Workaround
- Do not send requests exceeding the limits of Modbus RTU or Fast Modbus (265 bytes for Fast Modbus).
- Do not connect the device to a bus carrying non-Modbus traffic or messages longer than 265 bytes.
Resolution
Fixed in firmware 2.12.1.
ERRMODBUS009: Unexpected behaviour when reading near address 0xFFFF in continuous-reading mode
Affected devices
WB-MDM3 with firmware earlier than 2.12.1.
Description
With continuous-reading mode enabled, a read range reaching or crossing address 0xFFFF can freeze and reboot the device.
Cause and details
The continuous-reading algorithm did not handle overflow of the 16-bit register-address counter. Reading 0xFFFF wrapped the counter and caused an infinite loop, followed by a watchdog reset.
Workaround
With continuous-reading mode enabled, do not read a range including 0xFFFF. Wiren Board devices have no implemented register at that address.
Resolution
Fixed in firmware 2.12.1.
ERRMODBUS010: Incorrect request validation and handling of invalid requests
Affected devices
WB-MDM3 with firmware earlier than 2.12.1.
Description
The device may accept or mishandle syntactically invalid requests, return an incorrect exception code, or impose an incorrect register-count limit.
Cause and details
The validation algorithm mishandles these cases:
1) Requests to read zero registers succeed with an empty-data reply containing only a header and CRC. Modbus requires exception 0x03 (ILLEGAL_DATA_VALUE).
2) A single limit of 125 registers is applied to all read/write functions; exceeding it returns 0x02 (ILLEGAL_DATA_ADDRESS). Modbus instead specifies limits of 2000 bits for bit reads, 125 registers for input/holding reads, 1968 coils for multiple-coil writes, and 123 holding registers for multiple-register writes. Exceeding the applicable limit should return 0x03 (ILLEGAL_DATA_VALUE).
3) Byte Count is not validated for multiple writes (0x0F and 0x10). A mismatch between Byte Count and register count should return 0x03 (ILLEGAL_DATA_VALUE).
4) Single-coil writes do not validate the value and use the most significant bit of the request value. Modbus permits only 0x0000 and 0xFF00; all other values should return 0x03 (ILLEGAL_DATA_VALUE).
5) Structurally invalid requests with a valid CRC, such as overlong requests, are processed normally. Such malformed requests should instead be ignored.
6) Structurally valid but oversized frames of 257–265 bytes are processed. Standard Modbus frames longer than 256 bytes are invalid and should be ignored.
Workaround
Send only structurally correct requests compliant with the Modbus specification.
Resolution
Fixed in firmware 2.12.1.
ERRMODBUS011: Incorrect handling of invalid Fast Modbus event-configuration requests
Affected devices
WB-MDM3 with firmware earlier than 2.12.1.
Description
An event-configuration command (EVENT_CTRL, cmd=0x46, sub_cmd=0x18) with invalid length fields can configure event notifications incorrectly and produce a reply of unpredictable length.
Cause and details
The Fast Modbus event-configuration handler did not validate the size and internal data-block length fields. Invalid lengths can cause it to process data beyond the received frame, resulting in:
1) Incorrect event notification settings, including spontaneous changes to event priorities or masks.
2) An event-configuration reply of unpredictable length.
Workaround
Send only valid Fast Modbus commands compliant with its specification.
Resolution
Fixed in firmware 2.12.1.
ERRMODBUS012: Device stops transmitting Fast Modbus events
Affected devices
WB-MDM3 with firmware earlier than 2.12.3.
Description
The device stops sending Fast Modbus events and continuously reports no events (sub_cmd=0x12) in response to event requests (cmd=0x46, sub_cmd=0x10). Web-interface controls freeze while device registers continue to change.
The more frequently an event-enabled value changes, the sooner the issue occurs. In testing with 1 ms debouncing, event transmission stopped after 23 minutes at 200 input pulses per second and after several hours at 100 pulses per second. It can also occur with infrequent changes, but is much less likely. The driver logs no error because the device validly reports that no events are pending.
For diagnosis, read the register directly without events, for example the input pulse counter:
modbus_client_rpc -mrtu -pnone -s2 /dev/ttyRS485-1 -b115200 -a1 -r32 -t0x03
If the register increases but the web-interface control stays unchanged, this issue is present.
Cause and details
The unsent-event counter is shared by an interrupt handler and the main loop without correct synchronisation. An interrupt during a read-modify-write operation in the main loop can lose a counter increment. The increment cannot be recovered because it only occurs when an event first enters the queue. The device then believes it has nothing to send despite queued events.
The condition persists until the device reboots. Another event may temporarily flush the accumulated queue and update the control once, but the mismatch immediately returns. An installation with no other changes therefore appears frozen.
The probability increases with event frequency and bus load because concurrent accesses become more likely.
Workaround
Rebooting the device restores events until the issue recurs. Rebooting the controller or restarting wb-mqtt-serial does not help: the state is held in the device, and reconfiguring events does not reset it.
Reduce the probability by increasing input debounce time or disabling events for frequently changing registers. Until firmware is updated, read values directly from the registers.
Resolution
Fixed in firmware 2.12.3.
ERRMDM01: Dimmer failure when used with LED lamp power supplies
Affected devices
All MDM3 models.
Description
With some dimmable LED lamp power supplies (drivers / luminaire current sources), the dimmer fails, often with flashes and noise. Adjacent channels or even neighboring MDM3 dimmers on the DIN rail may also fail.
Cause and details
LED lamp power supplies have input capacitance and impedance (usually a resistor) to limit inrush current.
Capacitance and resistance values are not standardized. Good drivers have low inrush current; poor drivers may have very high inrush current.
High inrush current occurs in the MDM3 dimmer in these cases:
- Leading-edge dimming of a capacitive load
- Firmware v.2.1.0–v.2.2.0: inaccurate detection of input-voltage zero crossing (fixed in 2.2.1)
- Firmware v.2.1.0–v.2.3.2: dimming starts immediately at the configured lower limit. Fixed in 2.3.3
- When overcurrent protection trips (for example, for the reasons above), protection releases and the transistors turn on at an arbitrary point in the input waveform, causing still greater inrush current. Fixed in 2.4.0: after a protection trip, outputs turn off for 3 s, then restart normally.
High inrush current can then cause either:
- Internal circuitry failure due to interference, aggravated by PCB routing where power tracks form a loop. Adjacent channels or neighboring devices on the DIN rail may also fail.
- Protection turns off the transistors; with long wires, a voltage spike damages the protection diode or a transistor.
Resolution
Fixed in firmware 2.3.3 dated 11 February 2022. Soft start raises voltage from zero even with a nonzero lower limit, significantly reducing inrush current.
Recommendations
- Update device firmware to 2.3.3
- Choose dimming mode carefully! Dimmable power supplies require trailing-edge mode only.
- Test the dimmer with the intended luminaires before purchasing lighting for the whole building. The manufacturer treats dimmer failure in this case as a warranty claim.
ERRMDM02: Device freezes after approximately six weeks of continuous operation
Affected devices
All MDM3 models with firmware 2.2.3
Description
After approximately six weeks, the device stops executing commands and updating register values but continues replying over Modbus.
Resolution
Fixed in 2.2.4
ERRMDM03: Lamp flicker with unstable supply frequency
Affected devices
All MDM3 models
Description
Voltage-period detection can be missed. If the input frequency is unstable, for example with generator power, lamps may flicker. The sine-wave detector includes a noise filter accepting only periods from 19.5 to 20.5 ms (48.78–51.28 Hz).
Resolution
No fix planned in the near term
ERRMDM04: Increased wear of internal nonvolatile memory
Affected devices
All MDM3 models with firmware 2.2.3 and 2.2.4
Description
Every configuration or brightness change (even a long press changing brightness in steps of 1) writes channel states to internal EEPROM. Its documented endurance exceeds one million write/erase cycles, so the source considers even this frequency not dangerous, but unnecessarily high wear occurs.
Resolution
Fixed in 2.3.0
Writes limited to once per second.
ERRMDM05: Incorrect dimming-curve interpolation near range limits
Affected devices
All MDM3 models with firmware earlier than 2.3.2
Description
At 1% brightness, the raw PWM value could exceed the configured minimum-brightness value.
Resolution
Fixed in 2.3.2 dated 7 February 2022.
At 1% brightness, the PWM value now exactly matches the setting.
ERRMDM06: Power switches fully on at low Raw Duty values
Affected devices
All MDM3 models with firmware earlier than 2.3.2
Description
Manually writing Raw Duty values below 220 (trailing edge) or 320 (leading edge) to holding registers 90–92 caused the power switches to turn fully on.
Resolution
Fixed in 2.3.3 dated 11 February 2022.
Writing low Raw Duty values no longer turns the power switches fully on
ERRMDM07: LED lamps glow when the channel is off
Affected devices
All MDM3 models through batch v2.7A inclusive.
Description
Some LED lamps glow faintly when the dimmer channel is fully off.
Cause and details
Capacitance and residual conductivity of the power transistors and protection diode produce leakage current of approximately 50–100 µA, causing some LED lamps to glow faintly.
Workaround
- Use different lamps.
- Connect a 1–2 MΩ through-hole resistor between Out and neutral N.
Resolution
Since batch v2.7B, a 1 MΩ resistor is fitted between N and Out.
An RC network is planned for v2.8.
ERRMDM08: Communication errors at 115200 bit/s and 100% brightness
Affected devices
WB-MDM3 with firmware 2.5.0 and 2.5.1.
Description
Communication errors occur when all these conditions apply:
- Baud rate 115200 bit/s.
- Mains voltage applied to L and N.
- Trailing-edge dimming selected.
- One or more channels on at 100% brightness.
Cause and details
Incorrect logic at 100% brightness caused an internal loop to consume all microcontroller resources, resulting in Modbus errors at high baud rates.
Resolution
Fixed in firmware 2.5.2 dated 23 September 2022.
ERRMDM09: Closure counters for inputs 4–6 do not work
Affected devices
WB-MDM3 with firmware 2.6.0–2.6.5 inclusive.
Description
A firmware error prevented closure counters for inputs 4–6 (registers 35, 36, 37) from incrementing; they remained zero.
Resolution
Fixed in firmware 2.6.6 dated 3 July 2023.
ERRMDM10: Hardware overcurrent protection trips are not handled by software
Affected devices
WB-MDM3 with firmware 2.5.3–2.6.3 inclusive.
Description
A firmware error removes software handling of hardware overcurrent protection trips. The Overcurrent register is not set.
Normal operation is unaffected. During a short circuit or overcurrent, protection trips and the load is disconnected by hardware . Without software handling, however, the load restarts after approximately 200 ms without soft start, potentially causing high inrush current, repeated protection trips, overheating and sometimes dimmer failure.
Firmware 2.5.3–2.6.3 inclusive is not recommended for use.
Resolution
Fixed in firmware 2.6.4 dated 5 December 2022.
ERRMDM11: Turn-off delay in switching mode
Affected devices
WB-MDM3 with firmware 2.7.0
Description
A firmware error delays turn-off in switching mode if the channel brightness register contains a value above 1%.
The fader continues operating in switching mode and gradually reduces brightness. The channel actually turns off only when brightness reaches 0; until then it remains fully on.
Workarounds:
- Update firmware to 2.7.1
- Set switching-mode channel brightness to 1%. Control it through the coil register, or toggle the brightness register between 0 and 1
- Set Channel brightness decrease rate to 0
Resolution
Fixed in firmware 2.7.1 dated 22 November 2023.
ERRMDM12: Device freezes with certain configuration combinations
Affected devices
WB-MDM3 with firmware 2.7.0–2.9.1 inclusive
Description
Writing a lower dimming limit above the upper limit and turning the channel on caused the dimmer to freeze and restart via watchdog. The same happened when both limits were zero.
Workaround
The lower dimming limit must be below the upper limit. They must not both be zero. Change these settings while the channel is off.
Resolution
Fixed in firmware 2.9.2 dated 4 March 2025.
ERRMDM13: Initial dimmer brightness is zero
Affected devices
WB-MDM3 with firmware 2.8.0–2.9.1 inclusive
Description
A firmware error set default brightness to 0 instead of 50.
Resolution
Fixed in firmware 2.9.2 dated 4 March 2025.
ERRMDM14: Fail-safe timeout above 255 s cannot be written
Affected devices
WB-MDM3 with firmware 2.8.0–2.9.1 inclusive
Description
A firmware error limits register 8 (communication-loss timeout for Safety Mode) to 1–255 instead of 1–65534.
Resolution
Fixed in firmware 2.9.2 dated 4 March 2025.
ERRMDM15: Overheating and failure under sustained overvoltage
Affected devices
All WB-MDM3 versions earlier than 2.11
Description
TVS protection diodes connected across the MOSFET switches protect against brief overvoltage transients. Their energy absorption capacity is limited.
Sustained mains overvoltage lasting more than a few cycles can exceed this energy limit. The TVS diodes then fail and conduct uncontrollably even at nominal mains voltage, overheating components and sometimes melting the enclosure.
Resolution
Planned fix in version 2.11