Modbus Pro Scanner Advanced

Hi Andrzej, Thanks for pointing this out. You were absolutely right — the previous reassembly logic introduced a regression by assuming the response length from the request size. I've now refactored the TCP receive logic into a proper stream parser. Instead of waiting for a fixed length, it determines the frame size dynamically from the response itself (Exception = 5 bytes, FC03/FC04 = 3 + ByteCount + 2), so exception frames and shorter valid responses are handled correctly again. The receive buffer is also now persistent across reads, consuming one complete frame at a time while preserving any remaining bytes in the TCP stream. Thanks again for catching this regression. It led to a much cleaner and more robust implementation.

New problem — a regression introduced by the reassembly logic This is the most important thing to fix. The reassembly mechanism relies on the condition #receiveBuffer >= expectedLength, where in the block scan expectedLength = 3 + count*2 + 2 (it assumes a full, successful response). The problem: if the device replies with an exception frame (e.g. Illegal Address 0x02), that frame is only 5 bytes long. With a 20-register block, expectedLength is 45, so the condition 5 >= 45 is never satisfied → the readLoop keeps waiting for the rest of the data that never arrives → the watchdog only kills it after 1500 ms as a timeout. Consequences: "Illegal Address" detection in the block scan no longer works — exceptions are now counted as timeouts, and the code in parseResponse that handles fCode >= 0x80 is effectively unreachable. The same mechanism breaks the "device returns fewer registers than requested" fail-safe — a shorter-than-expected but valid frame will also never reach expectedLength and ends in a timeout. On a device with sparsely populated registers, every such block now costs a full 1.5 s — the scan can take a very long time.

Hi Andrzej, Thank you so much for taking the time to review the code. Your insights are incredibly accurate and highlight some critical flaws in how the QuickApp handles TCP/IP and Modbus addressing. You are absolutely right that treating TCP as a packet-based protocol rather than a stream, and failing to manage sockets properly, are recipes for disaster on an OT network. Based on your feedback, I have refactored the code to address these issues: 1. Persistent TCP Connection & Socket Leak Fix: Instead of opening a new socket for every single request, the app now establishes a persistent connection when scanning starts and properly calls sock:close() upon completion or whenever a connect_error/timeout occurs. This prevents socket exhaustion and avoids hammering the gateway. 2. 0-based Register Addressing: I've added a -1 offset when building the RTU frame so that user-facing inputs (1-based) align correctly with Modbus wire addresses (0-based). 3. TCP Reassembly / Buffered Reading: I've introduced a basic receiveBuffer to accumulate incoming TCP fragments until the expected Modbus RTU frame length is met, preventing dropped data on larger block sizes. 4. Live Stats Update: self:refreshStats() is now explicitly called inside the processing loop so the UI updates in real-time during the scan. 5. Auto Scan Slave Delay: Increased the delay and added a warning mechanism to prevent aggressive 50ms polling from crashing shared RS-485 networks. Here is the updated core logic implementing your suggestions. Thanks again for the pro-level review!

Potencial problems Register addressing (1-based vs 0-based). The scan starts at register 1 and puts 0x0001 on the wire. Modbus wire addresses are 0-based, so what a device datasheet calls "register 1" (40001) usually sits at wire address 0. Readings can therefore be off by one relative to what you expect — keep this in mind when interpreting results. No TCP reassembly. sock:read reads only once. If a response arrives split across multiple TCP packets, the code (correctly) rejects the frame on a length mismatch, but the data for that whole block is lost. With 20-register blocks this is a real risk on some gateways; reducing blockSize works around it. A new socket per request. Every read opens and closes a separate TCP connection. Many ZLAN-type gateways accept only one client and release the socket slowly, so rapid requests (50–150 ms apart) can produce "connection refused" errors. If the scan stalls, increase the delays. Stats don't update live. The timeout/"Empty" counter is never incremented, and refreshStats() is never actually called during a scan, so the statistics line doesn't refresh while scanning. Cosmetic only. Inconsistent endReg default. The QuickApp variable is 500, but initVariables and resetSettings use 150. Harmless, but confusing. Socket not closed on connect failure. The connect_error path doesn't call sock:close() or clearTimeout. When mass-scanning toward an unreachable gateway, sockets can briefly accumulate. binarySwitch device type. Because the app is a binary switch, accidentally turning the device "on" (from a scene or a voice assistant) will launch a full scan. Don't include it in scenes. Operational limitation (not a code bug). The "FIND ID SLAVE" routine sends 255 requests at 50 ms intervals. On a shared RS-485 bus that another master (PLC/SCADA) is already polling, this aggressive scanning can cause collisions and disrupt live communication — so it shouldn't be run on a production OT network while it's in use.