Wiren BoardDocumentation
Documentation / Reference
Reference · English

WB-LED known issues

revision 90980

ERRMRGBW-D04: Hue values do not change in MQTT during continuous RGB strip colour change

Affected devices

WB-MRGBW-D and WB-LED since version 3.4.1.

Description

In RGB + W mode, continuous RGB colour change deliberately does not generate Hue register events. Hue changes very frequently and would generate excessive bus traffic. Devices with addresses higher than the WB-LED or WB-MRGBW-D address would then be likely to miss polling.

Workaround

Edit the device template: in the register section RGB Strip Hue (address 2014), set the parameter sporadic to false.

Resolution

Update the Wiren Board controller to release wb-2407 or later. If wb-2407 is already installed, update its packages. This update disables Hue register events.

Since firmware 3.8.0, Hue events are generated again during continuous colour change: a delay limits the event rate during automatic hue adjustment to avoid overloading the bus. In WB-LED and WB-MRGBW-D templates from wb-mqtt-serial 2.255.0, RGB Strip Hue (address 2014) again uses sporadic mode. The manual workaround is no longer required.

ERRMRGBW-D05: Power-on and safe-mode actions do not work correctly

Affected devices

WB-MRGBW-D and WB-LED with firmware 3.5.0 through 3.5.2 inclusive.

Description

In the following operating modes:

  • any mode with a CCT strip
  • RGB+W

power-on and safe-mode actions operate incorrectly.

The wb-mqtt-serial template also has incorrect power-on action labels: read No action as Switch off, and Switch off as Restore previous state.

Resolution

Fixed in firmware 3.5.3 and wb-mqtt-serial v2.157.1. Update the device firmware and controller software.

ERRMRGBW-D06: Press-type action configuration registers work incorrectly

Affected devices

WB-MRGBW-D and WB-LED with firmware 3.5.0 through 3.5.2 inclusive.

Description

Action configuration registers at addresses 768–819 and 832–883 work incorrectly.

Workaround

Use registers 1000–1063 to configure actions.

Resolution

No fix is planned. The faulty registers were removed from firmware starting with 3.5.3.

ERRMRGBW-D07: Channel level registers reset to defaults at dimmer power-on

Affected devices

WB-MRGBW-D and WB-LED with firmware 3.5.0 through 3.5.2 inclusive.

Description

A firmware bug caused channel levels to load their default values at power-on instead of the values present at power-off.

Resolution

Fixed in firmware 3.5.3. Update the device firmware.

ERRMRGBW-D08: Input actions always work in safe mode, regardless of settings

Affected devices

WB-MRGBW-D and WB-LED with firmware 3.5.0 through 3.5.2 inclusive.

Description

A firmware bug makes input actions from pushbuttons or switches always operate in safe mode, regardless of the Input control in safe mode setting.

Resolution

Fixed in firmware 3.5.3. Update the device firmware.

ERRMODBUS001: Device replies to address 0xFD

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.4.4.

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 3.4.4.


ERRMODBUS002: Incorrect response to discovery command 0x46

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.4.2.

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 3.4.2.

Resolution

Fixed in firmware 3.4.2.


ERRMODBUS003: Unexpected behaviour when invalid values are written to some registers

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.5.3.

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 3.5.3.

Resolution

Fixed in firmware 3.5.3.


ERRMODBUS004: Incorrect bit-field replies

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.4.2.

Description

Replies containing bit fields, including coil/discrete reads and event management, could contain incorrect high bits.

Remedy

Update firmware to 3.4.2.

Resolution

Fixed in firmware 3.4.2.


ERRMODBUS005: Incorrect reading of different coil registers in one request

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.4.4.

Description

Reading several different coil registers at consecutive addresses in a single request returned incorrect values; examples include 2 and 3 in WB-MSW/WB-MWAC, or 3 and 4 in WB-LED.

Remedy

Update firmware to 3.4.4.

Resolution

Fixed in firmware 3.4.4.


ERRMODBUS006: Responses to requests with incorrect parity

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.5.1.

Description

The device replied to requests with incorrect parity instead of ignoring them.

Remedy

Update firmware to 3.5.1.

Resolution

Fixed in firmware 3.5.1.


ERRMODBUS007: Lost events when two devices transmit simultaneously on one bus

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.8.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 3.8.0.


ERRMODBUS008: Unexpected behaviour with long request frames

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.8.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 3.8.1.


ERRMODBUS009: Unexpected behaviour when reading near address 0xFFFF in continuous-reading mode

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.8.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 3.8.1.


ERRMODBUS010: Incorrect request validation and handling of invalid requests

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.8.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 3.8.1.


ERRMODBUS011: Incorrect handling of invalid Fast Modbus event-configuration requests

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.8.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 3.8.1.


ERRMODBUS012: Device stops transmitting Fast Modbus events

Affected devices

WB-MRGBW-D and WB-LED with firmware earlier than 3.9.2.

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 3.9.2.


ERRLED0001: No short-press action configured for inputs 1–3

Affected devices

All WB-LED v1.3A, v1.3A/T, v1.3C, v1.3H, v1.3I, v1.3I/1, v1.3I/2, v1.3J/1, v1.3J/1A, v1.3J/2, v1.3J/2A, v1.3K, v1.3L, v1.3M, v1.3M/1, V1.4A, V1.4A/1, v1.4A/2, v1.4B, v1.4B/1, v1.4C, v1.5A, v1.5A/1, v1.5A/2, v1.5A/3, v1.5B, v1.5B/1, v1.5B/2, v4.3M

Description

A manufacturing test error prevented restoration of default settings after testing. Devices left production with incorrect parameters:

  • Input 1 short-press action: Disabled instead of Toggle RGB
  • Input 2 short-press action: Disabled instead of Increase RGB strip hue (HSV-H, with wraparound)
  • Input 3 short-press action: Disabled instead of Toggle channel 4

Workaround

  • Use the controller web interface and device template to set the corresponding values
  • Manually write 0x3009 to register 0x1000, 0x900e to 0x1001 and 0x3003 to 0x1002

Resolution

Fixed in batch v1.5B/3

ERRLED0002: Incorrect phase inversion in 4W mode

Affected devices

All WB-LED devices with firmware 3.5.0 through 3.6.0 inclusive.

Applies to 4W mode, with all channels connected in parallel.

Description

To distribute the power supply load evenly, channel pairs 1–2 and 3–4 operate in opposite phase, except in 4W mode.

A firmware bug loaded the phase inversion setting incorrectly from nonvolatile memory at startup. Channel pairs 1–2 and 3–4 therefore always operated in opposite phase, even in 4W mode with all channels in parallel. This could trip overcurrent protection. Phase inversion works correctly after changing the mode to 4W until the next reboot.

Workaround

  • preferred: update firmware to 3.6.1 or later
  • after rebooting, change to another mode and then back to 4W

Resolution

Fixed in firmware 3.6.1.

ERRLED0003: Incorrect recovery after overcurrent trips for parallel channels

Affected devices

All WB-LED devices with firmware up to and including 3.6.0.

Applies to dimmer modes 2W+W+W, W+W+2W, 2W+2W, CCT+2W, 2W+CCT and 4W.

Description

A firmware bug switches channels on one at a time after overcurrent protection trips, even when the operating mode requires parallel channels. This may exceed the current limit of an individual channel and trip protection again.

Workaround

Update firmware to 3.6.1 or later.

Resolution

Fixed in firmware 3.6.1. Parallel channels switch on simultaneously.

ERRLED0004: Dimmer cannot operate at full load with parallel channels

Affected devices

All WB-LED devices with firmware up to and including 3.6.0.

Applies to dimmer modes 2W+W+W, W+W+2W, 2W+2W, CCT+2W, 2W+CCT and 4W.

Description

A firmware bug updated PWM values asynchronously, allowing one parallel channel to switch on before the others. Current then flowed through only one transistor until the other parallel transistors switched on, tripping hardware overcurrent protection.

Workaround

Update firmware to 3.6.1 or later.

Resolution

Fixed in firmware 3.6.1. PWM is applied synchronously to parallel channels.

ERRLED0005: Total CCT strip channel power is not normalized

Affected devices

WB-LED and WB-MRGBW-D with firmware up to and including 3.6.1

Applies to dimmer modes CCT+W+W, CCT+2W, W+W+CCT, 2W+CCT and CCT+CCT.

Description

The CCT mixing algorithm does not maintain constant total power. Power increases as colour temperature approaches the middle of the range, reaching its maximum at 50%, when both channels operate at full brightness.

Workaround

Update firmware to 3.7.0 or later. Enable CCT strip power normalization.

Resolution

Fixed in firmware 3.7.0