Connecting with multicast interface requests to the bus are always flaged with repeated=true

[lewie]

Hello @bmalinowsky,

when connecting calimero by multicast interface to a KNX bus, all requests (respond or write) coming from calimero have set the "RepeatedFlag" flag to true. Debugged with ETS5.

This is definitively not correct, because it is not a repeated! It also has the side-effect, that repeated request without previous external bus transactions from other devices, can not be answered by calimero.

It seams with a connection by TUNNEL, requests are correctly flagged.

I connected with several calimero tools and examples (ProcComm and PushButtonActuator etc.) same effect. I only can prevent it hardcoded over CEMILData.setRepeat().

I do not understand all backgrounds to fix the error in calimero.

Thank you in advance. Helmut

[bmalinowsky]

Hi, thanks I will look into that.

Can you elaborate on the side-effect you mentioned wrt responses that cannot be answered by calimero? Especially the setup (KNX subnet medium) and calimero version you use? The reason is, you mention the PushButtonActuator example, it uses KNX IP. The repeat flag is not relevant here, as it does not apply on that medium.

For now, I tried the push-button example, but it updates and answers fine from what I can see.

[lewie]

Hi, using KNX IP as ROUTER as multicast interface (224.0.23.12:3671) then RepeatedFlag=true at all communication to the knx bus.

Log ETS5 RepeatedFlag=true: Makes no sense.

Log ETS5 RepeatedFlag=true and READ does not work without Busaction:: The side-effect.

Log ETS5 READ does work correct:: Calimero 2.3 beta, hardcoded RepeatedFlag always false

To force calimero to RepeatedFlag=false I manipulated tuwien.auto.calimero.cemi.CEMILData::setRepeat().

Think now it is more clear what I mean. ;-) Helmut

PS:

For now, I tried the push-button example, but it updates and answers fine from what I can see.

Does push-button example answer a groupReadRequest coming from the bus? Mine doesn't...

EDIT: Oh yes, it does answer, sorry! So it is a perfect test environment, I get exactly the same effects!

EDIT2: Is there a example for best practice to dispatch a value change of a calimero device to the bus? Or simply use BaseKnxDevice? There is missing the ability to dispatch or visibility of ProcessServiceNotifier should be changed. Or should I do it best with ProcessCommunicationResponder directly?

[bmalinowsky]

That routing indications show up as repeated makes no sense, thank you for pointing that out! Should be fixed with @97ea2e20e3c67f110c6219639280d97409d9fd04.

However, I tested two setups, 1) using a pure KNX IP network with your pushbutton example, as well as 2) a routing backbone attached to PL110. In both cases the repeat flag made no difference (if it's set or not, which makes sense).

[bmalinowsky]

Wrt. EDIT2: you use the standard process communicator. For example with the pushbutton, switch it every 5 seconds in run() (make device a field):

while (true) {
    wait(5000);
    try (ProcessCommunicator pc = new ProcessCommunicatorImpl(device.getDeviceLink())) {
        pc.write(dpAddress, state ^= true);
    }
    catch (KNXLinkClosedException | KNXTimeoutException e) { e.printStackTrace(); }
}

[lewie]

In my push-button Setup (ROUTER as multicast interface (224.0.23.12:3671)) it works perfect now! Later I will test it with TUNNELING Setup and in OpenHAB Bundle.

Your example with ProcessCommunicator works perfect!

Thank you very much! Helmut

[lewie]

OK, TUNNELING is working too in OpenHAB it works perfect. We can close this.

I had forgotten: When I use the original example PushButtonActuator.java I get:

Multiple markers at this line 140

• The resource type KNXNetworkLink does not implement java.lang.AutoCloseable
• The resource type KNXNetworkLinkIP does not implement java.lang.AutoCloseable

Add extends AutoCloseable to KNXNetworkLink helped me.

[bmalinowsky]

Wrt EDIT2, part 2: ofc, there might be reasons to override dispatching and threading of service notifiers. If so, please open a new issue to allow that. Otherwise, it's basically an implementation detail. ProcessCommunicationResponder is used to send AL responses (and only those!).

PushButtonActuator:

Multiple markers at this line 140

The resource type KNXNetworkLink does not implement java.lang.AutoCloseable The resource type KNXNetworkLinkIP does not implement java.lang.AutoCloseable

Yes, it's a Java 8 example, so it uses Calimero Java SE Embedded 8, not the old Java ME CDC (where Closeables were not born yet ;).