fix: Correct FC5/FC6 Modbus response to echo requested value

[thiagoralves]

Summary

• Fixes Modbus FC5 (Write Single Coil) and FC6 (Write Single Register) responses to correctly echo the requested value per Modbus specification
• Introduces OpenPLCDeviceContext class that caches write values for proper response echo
• Uses asyncio task ID to isolate concurrent requests, preventing race conditions

Problem

When using libmodbus to write a coil via FC5, the coil was written successfully but libmodbus reported an error because the response didn't match the request:

• Client sends 0xFF00 (ON)
• Server responds with 0x0000 (the previous value)

This happened because:

1. pymodbus implements FC5/FC6 by calling setValues() then getValues() and using the read-back value
2. OpenPLC uses a journal-based write system where writes are applied at the next PLC scan cycle
3. The getValues() read-back returned the old buffer value before the journal write was applied

Solution

Created OpenPLCDeviceContext that:

1. Caches values when setValues() is called with FC5 or FC6
2. Returns cached values when getValues() is called with FC5 or FC6
3. Uses asyncio task ID as part of the cache key to isolate concurrent requests

This ensures FC5/FC6 responses correctly echo the requested value without introducing a double-buffer synchronization mechanism.

Test plan

• Test FC5 (Write Single Coil) with libmodbus - verify no error reported
• Test FC6 (Write Single Register) with libmodbus - verify no error reported
• Test concurrent FC5 requests to same coil address
• Test FC1 (Read Coils) still reads actual buffer values
• Test FC15 (Write Multiple Coils) still works (doesn't use echo)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes Modbus FC5 (Write Single Coil) and FC6 (Write Single Register) responses to correctly echo the requested value per Modbus specification, resolving an issue where libmodbus reported errors due to response/request mismatches.

Changes:

• Introduces OpenPLCDeviceContext class that caches write values for FC5/FC6 operations
• Uses asyncio task ID to isolate concurrent requests and prevent race conditions
• Replaces ModbusDeviceContext with OpenPLCDeviceContext in device initialization

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The _pending_writes dictionary is not thread-safe and could lead to race conditions if multiple asyncio tasks access it concurrently. Consider using asyncio.Lock() to protect access to this shared state, or use a thread-safe data structure.

[Copilot]

Cache entries are removed immediately upon read, which could cause issues if getValues() is called multiple times for the same request. Consider whether the cache should persist until the request is complete or implement a more robust cache invalidation strategy.

Suggested change

	results.append(self._pending_writes.pop(cache_key))
	else:
	all_cached = False
	break
	if all_cached:
	return results
	# If not all values were cached, clean up any partial cache entries
	# and fall through to normal read
	for i in range(len(results), count):
	# Read cached value without removing it yet; we'll clear the cache
	# for the full address range once we've confirmed all values exist.
	results.append(self._pending_writes[cache_key])
	else:
	all_cached = False
	break
	if all_cached:
	# All values were cached: now invalidate the entire range for this task.
	for i in range(count):
	cache_key = (task_id, func_code, address + i)
	self._pending_writes.pop(cache_key, None)
	return results
	# If not all values were cached, clean up any partial cache entries
	# and fall through to normal read
	for i in range(count):

[Copilot]

The _pending_writes cache grows unbounded and never clears stale entries if tasks fail or don't complete normally. Consider implementing cache expiration or cleanup logic to prevent memory leaks from orphaned task entries.