DocumentationWB-M1W2 v.3 known issues
About this page
This page describes known issues for WB-M1W2 v.3.
ERRMODBUS003: Unexpected behaviour when invalid values are written to some registers
Affected devices
WB-M1W2 v.3 with firmware earlier than 4.33.6.
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 to firmware 4.33.6.
Resolution
Fixed in firmware 4.33.6.
ERRMODBUS006: Responses to requests with incorrect parity
Affected devices
WB-M1W2 v.3 with firmware earlier than 4.33.5.
Description
The device replied to requests with incorrect parity instead of ignoring them.
Remedy
Update to firmware 4.33.5.
Resolution
Fixed in firmware 4.33.5.
ERRMODBUS007: Lost events when two devices transmit simultaneously on one bus
Affected devices
WB-M1W2 v.3 with firmware earlier than 4.35.2.
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 4.35.2.
ERRMODBUS008: Unexpected behaviour with long request frames
Affected devices
WB-M1W2 v.3 with firmware earlier than 4.35.3.
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 4.35.3.
ERRMODBUS009: Unexpected behaviour when reading near address 0xFFFF in continuous-reading mode
Affected devices
WB-M1W2 v.3 with firmware earlier than 4.35.3.
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 4.35.3.
ERRMODBUS010: Incorrect request validation and handling of invalid requests
Affected devices
WB-M1W2 v.3 with firmware earlier than 4.35.3.
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 4.35.3.
ERRMODBUS011: Incorrect handling of invalid Fast Modbus event-configuration requests
Affected devices
WB-M1W2 v.3 with firmware earlier than 4.35.3.
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 4.35.3.
ERRMODBUS012: Device stops transmitting Fast Modbus events
Affected devices
WB-M1W2 v.3 with firmware earlier than 4.36.0.
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 4.36.0.
ERRM1W2301: DS18B20 strong pull-up remains enabled after changing between counting/press detection and 1-Wire modes
Affected devices
All devices with firmware up to 4.33.3.
Description
The DS18B20 strong pull-up is enabled during temperature conversion. If the input mode changes at that moment, the pull-up may remain enabled, preventing Counting and press detection mode from working. This can also overheat and damage the device.
Cause and details
Caused by a firmware error.
Resolution
Fixed in firmware 4.33.4, released 12 August 2024.
Workaround
To change the input mode on affected firmware: power off the device, disconnect the DS18B20, power on, then change the mode.