Connecting with multicast interface requests to the bus are always flaged with repeated=true about calimero-core HOT 7 CLOSED

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.

from calimero-core.

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?

from calimero-core.

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).

from calimero-core.

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(); }
}

from calimero-core.

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

from calimero-core.

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.

from calimero-core.

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 ;).

from calimero-core.