DNP3 Event Buffer Backfilling - Wireshark and logs seem good

I've got a DNP3 outstation connected and setup all the things that should enable backfilling of buffered class event data (i.e. history enabled set to onChange, tag group set to subscribed, OPC-UA sampling interval: 0, queue size: > 0 (250); dnp3 device class 1 unsolicited msging turned on, set to 2500 ms rate) however i'm not getting buffered events stored into the historian. FWIW, it's working for 61850 using their reports and i'm utilising the same tag group for testing.

I can see the buffered events come into IGnition via both Ignition's logs and wireshark's:

but no data gets put into the history (testing with the Core Historian)...

Anyone have any ideas?

Claude reckons it's a race condition, see below (Claude's words not mine!):

I found the cause: buffered events are lost only after a reconnect.

The event data is fine. The events are g32v7 (float with time). In the capture, the first buffered event is stamped 11:58:12 UTC and the burst arrives at 11:59:10 UTC (22:29:10 local, ACDT). The driver parses all 100 points correctly (GROUP32_VAR7, isEvent=true). The response also had IIN2.3 Event Buffer Overflow set, so some events were lost at the outstation, but the 100 that arrived should still have been stored.

The problem is the timing on reconnect. The Dnp3Device logs show a new EventAddressSpace being registered in the same second the backlog is handled:

22:28:00  unregistered EventAddressSpace@4155e5b1
22:29:10  registered   EventAddressSpace@4787f830
22:29:10  EventAddressSpace  handleAnalogInput: variation=GROUP32_VAR7, isEvent=true, points=[...100 points...]

None of those events reach history. The trend shows a clean gap and then live data resumes.

Without a reconnect, it works. I left the connection up and made the class 1 poll interval much longer, so events built up in the outstation between polls. All of them came through with their own timestamps and were stored in the Core Historian. So the tag group, history settings, sampling interval of 0 and queue size are all fine, and the driver does pass events through with their own timestamps.

It looks like the startup integrity/event poll delivers the backlog to the new address space before the tags' OPC UA monitored items have re-attached to it, so the queued values are dropped. That's unfortunate, because recovering events after a comms outage is exactly what event buffers are for. IEC 61850 buffered reports don't have this problem, presumably because the RCBs are enabled after the subscriptions are back.

Is this a known issue with the DNP3 v2 driver? Could the post-reconnect integrity poll wait until the address space is registered and the subscriptions have re-attached, or is there a setting that delays it? Happy to provide captures or logs.

Oh, this appears to be an issue with my testing method of disabling the device instead of just disconnecting it like a normal person :face_with_hand_over_mouth:

I will try that instead... except my DNP3 outstation is a simulator.

In this case, it's less technically a bug

If the simulator is running in a VM, you could simply use the hypervisor's tools to "unplug" its network link. Trivial with virt-manager + QemuKVM in Linux.

Nah they're both just just running on my laptop. I just got Claude to add a toggle to reject connection from selected masters in the simulator it wrote for me :face_with_hand_over_mouth:

The DNP3 driver doesn’t backfill on startup (or edit/save), only on reconnecting after a connection loss.