# Device implementation, managing system.opc.read request

**URL:** <https://forum.inductiveautomation.com/t/device-implementation-managing-system-opc-read-request/110382>\
**Category:** Module Development\
**Tags:** ignition81\
**Created:** [September 4, 2025, 3:29pm UTC](https://forum.inductiveautomation.com/t/device-implementation-managing-system-opc-read-request/110382 "2025-09-04T15:29:20Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\
**Post date:** [September 4, 2025, 3:29pm UTC](https://forum.inductiveautomation.com/t/device-implementation-managing-system-opc-read-request/110382/1 "2025-09-04T15:29:20Z")

</div>

Ignition 8.1,

In a module driver implementing the **Device** interface\*\*,\*\* I’m looking for the method for managing **system.opc.read** responses.

With **AbstractTagDriver** , we just have to override this method:

```java
@Override
// readItems(java.util.List<? extends ReadItem> items)
// Asynchronous read call for a list of items.
public void readItems(List<? extends ReadItem> items){

```

```python
system.opc.readValue(opcServer, itemPath)

```

return the value from the opcua server, but we probably want to process a synchronous request to the device ?

I suppose we need to add a filter to the node, but it will concern all read operation ?

```python
  // an AttributeFilter is used so that when this node is asked for its value, it will call out to the
  // simulator
  node.getFilterChain().addLast(AttributeFilters.getValue(
      getAttributeContext ->
          simulator.getTrackedValue(formattedName))
  );

```

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [September 4, 2025, 4:03pm UTC](https://forum.inductiveautomation.com/t/device-implementation-managing-system-opc-read-request/110382/2 "2025-09-04T16:03:26Z")

</div>

If you're using a ManagedAddressSpace like the SDK example does then adding a filter is the way to intercept attributes reads of UaNode instances.

If you need to do something smart, group the reads, reach out to a device, etc... then you want to override `AddressSpace::read` with your own logic for servicing a read request.

---

<div class="post-metadata">

**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\
**Post date:** [September 4, 2025, 6:00pm UTC](https://forum.inductiveautomation.com/t/device-implementation-managing-system-opc-read-request/110382/3 "2025-09-04T18:00:33Z")

</div>

can we have long-lasting operations (few seconds) in AddressSpace::read or AddressSpace::write method ?  
or it will block the caller and we have to avoid that ?

I was thinking of adding synchronous request to the device in **AddressSpace::write**?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [September 4, 2025, 6:05pm UTC](https://forum.inductiveautomation.com/t/device-implementation-managing-system-opc-read-request/110382/4 "2025-09-04T18:05:34Z")

</div>

Yes, you can block. It will block the thread servicing the request in the OPC UA server, but that's expected.