[basicprofiles] Initial contribution

[cweitkamp]

• Initial contribution of Basic Profiles bundle

Signed-off-by: Christoph Weitkamp github@christophweitkamp.de

[J-N-K]

Thanks. These look like great additions. I have left some comments.

[J-N-K]

Is that correct? I thought that sendUpdate updates the item's state. But shouldn't this result in a state that is processed by the handler?

[cweitkamp]

No. Round is a one-way Profile. It should be applied only in updates / commands from handler towards Item.

[J-N-K]

@cweitkamp I would like to come back to this comment, as the current implementation causes issues with latest core changes. I also came across this when using the invert/negate profile.

As a result of this line we end up in an endless loop:

1. The item updates its state to 123.12 and sends an ItemStateUpdatedEvent with a state of 123.12.
2. The CommunicationManager forwards this state update to the and according to its configuration the profile rounds that to 123 and forwards that to the callback's sendUpdate method.
3. The callback issues an ItemStateEvent which is received by the item, which sets its state to 123. After that, it sends an ItemStateUpdatedEvent with a state of 123.
4. The CommunicationManager receives that, ... (start again at 2).

the same issue arises with the invert profile, because CLOSED is inverted to OPEN and after updating the item state to OPEN it is again inverted to CLOSED, resulting in the same update loop.

We can't prevent that by checking event source, because the ItemUpdater (that receives the ItemStateEvent) calls GenericItem.setState (which creates the ItemStateUpdatedEvent/ItemStateChangedEvent) and the source is lost (otherwise we could have set the source of the ItemStateUpdatedEvent to the same value as the ItemStateEvent.

IMO a profile should only change values that are transferred from the handler to the item (or from the item to the handler), not interact with the item state itself.

[LukasA83]

And, obviously, it is right now a blocking issue to migrate to OH 4 with M2 or newer snapshots, so maybe this can be resolved somehow.

[cweitkamp]

Your explanation sounds reasonable. I won't argue against it. Feel free to change/remove this part of code.

[cweitkamp]

After upgrading to latest OH milestone I am suffering from this myself. I submitted #478 to fix this.

[cweitkamp]

One more question. Should I contribute against the "main" branch?

[J-N-K]

Just two comments. Otherwise looks good. Jenkins fails unrelated.

Regarding the branch: I sync both branches manually by cherry-pciking the commits, so it doesn't matter wher you contribute. Just use what better fits your need.