Reporter initialization

[balazsracz]

When we create a new Reporter object in JMRI (according to DccDetectorWN), it does not query the current state of the reporter. As such, only reports that come in after JMRI was started are visible.

We should update the code so that upon startup / object creation, the state query message is sent out. Then observe the incoming state messages and populate the initial state of the reporter from that.

[bobjacobsen]

I haven't worked with event ranges much. Is is sufficient to send an Identify Producer for the first address in the range? Will that get back a ProducerIdentified(Valid) for the most recent report event?

[balazsracz]

We are actually missing an interaction from the WN that would spec out how a query should be handled.

Based on my opensource implementation I have code that does this:

• if IDENTIFY_PRODUCER with suffix 0000 arrives, then
• sends out PRODUCER_IDENTIFIED_VALID for all currently valid reports.

I think this is somewhat buggy because it does not send an INVALID message when long address 0 is not present in the block. But I think I can fix that bug.

The difficulty in this interaction is that the caller can't really know when the set of reports have stopped coming on the bus (i.e., there are no more reports).

[bobjacobsen]

it does not send an INVALID message when long address 0 is not present in the block.

Instead of that, would it make sense to send back a Producer Range Identified for the corresponding range?

The difficulty in this interaction is that the caller can't really know when the set of reports have stopped coming on the bus (i.e., there are no more reports).

For JMRI, I don't think this matters. As the messages come in, reports are updated. There really isn't a "no more" case.

[balazsracz]

On Sat, Sep 19, 2026 at 2:07 PM Bob Jacobsen ***@***.***> wrote: *bobjacobsen* left a comment (openlcb/OpenLCB_Java#308) <#308 (comment)> it does not send an INVALID message when long address 0 is not present in the block. Instead of that, would it make sense to send back a Producer Range Identified for the corresponding range?

I'm not sure I understand the proposal here.

The difficulty in this interaction is that the caller can't really know when the set of reports have stopped coming on the bus (i.e., there are no more reports). For JMRI, I don't think this matters. As the messages come in, reports are updated. There really isn't a "no more" case.

This means that we will have to implement handling if PRODUCER_IDENTIFIED_VALID messages in a way that they are equivalent of EVENT_REPORT messages. This is definitely doable, but it is unclear whether that is a good idea. Historically I had code like that implemented for the event-pair-to-bit consumer/producer used in the sensor/turnout implementations, but it turned out to be a bad idea, as random nodes ended up triggering this codepath during their initialization. Message ID: ***@***.***>

…

[bobjacobsen]

would it make sense to send back a Producer Range Identified for the corresponding range?

I'm not sure I understand the proposal here.

Sorry, I was too schematic in my reply.

When an IDENTIFY_PRODUCER with suffix 0000 arrives, I think it makes sense to resend the PRODUCER_RANGE_IDENTIFIED.

Given the below, I think it would also make sense to send the PRODUCER_IDENTIFIED for the long-address-zero with the appropriate valid or invalid indication.

The difficulty in this interaction is that the caller can't really know when the set of reports have stopped coming on the bus (i.e., there are no more reports).

For JMRI, I don't think this matters. As the messages come in, reports are updated. There really isn't a "no more" case.

This means that we will have to implement handling if PRODUCER_IDENTIFIED_VALID messages in a way that they are equivalent of
EVENT_REPORT messages. This is definitely doable, but it is unclear whether that is a good idea.
Historically I had code like that implemented for the event-pair-to-bit consumer/producer used in the sensor/turnout implementations, but it turned out to be a bad idea, as random nodes ended up triggering this codepath during their initialization.

I think the OlcbReporter is already handling the valid/invalid cases of PRODUCER_IDENTIFIED. I don't think there's been enough use of this to know whether it's going to create problems.