Vision of the structure of the Controls

[TCke83]

Hi,

i was looking further into the library and i have a few questions.

I want to zoom in on the SwitchControl, but a lot of other controls will show simular behaviour i guess.

The SwitchControl object now contains the structure data of the control, but shouldn't it also contain the current state of the control in the miniserver ('On' or 'Off) and also expose the supported commands (switch 'On' or 'Off' or 'Toggle', ...)

What is the idea for further development of the library? If the SwitchControl object should know it's state we should get the current state from the miniserver (lazy loaded maybe ??) and also be able to trigger commands on the control itself? The state can be retrieved by an active state query (not entirely clear how to do that) and should also get updates when an update is send through the websocket for the specific control.

This leads to the problem the SwitchControl needs to have access to the Loxone class to be able to send commands (or at least the open websocket).

Is this the way forward, or do you guys have other ideas about it?

I can try to focus on the SwitchControl and try to implement what I have in mind.

[jimirocks]

Hi,

First, there are no specific plans on that. Currently the Control classes are only DTOs representing the part of the Loxone APP structure.

Second, if I understand your ideas well, you propose to use some kind of active record pattern - to implement some dynamic behaviour on the control classes. While this may look nice at first sight, there are couple problems at second sight - you named some of them. My experience (coming from other API client projects) rather support the idea of having the dynamic logic separate. Which is actually what is represented now by sendControl* methods and also LoxoneEventListener.

To sum up:

• let's avoid active record pattern
• let's try to implement new dynamic logic by improving and extending the current Loxone class methods and LoxoneEventListener - I admit that currently it's may be too generic (but was sufficient to our needs so far)
• if you have any usecase in your application using the library I strongly recommend to prototype and play with the contribution ideas in the scope of your app first which will help you to realize which parts are generic enough to be contributed to the library later - I will be happy to read some usecase code supporting your ideas.

[TCke83]

Hi,

thanks for the reply. I agree the active record pattern has its drawbacks. But the sendControl* methods will soon explode I guess if we want to have a method for setting every property on every type of control that is available. I don't know how you see this evolve in the future?

Also I would like to keep track of the state of the controls. Let's again take the SwitchControl as example, I want to know if the current state is 'On' of 'Off' to make it visible in my app. I don't think it is a good idea to send a request to the miniserver every time if I want to know the state. We should keep track of it I think. I can call .setEventsEnabled(true) to get all the updates of the controls and at connection time get the state of all controls. I guess we should capture the state of the controls. Do you have an idea how you want to see that implemented? I think the events should be handled by the library and the result should be available. We now have the structure file in DTO format, but I think we should also have the state in some kind of format that allows easy mapping between DTO en current state.

I think the 'raw' events of the miniserver should not directly be propagated to users of the library, it could be the state doesn't change, or something that is not exposed changes, the user of the library should not get an update I guess.

What are your thoughts and/or suggestions on that aspect?

[jimirocks]

Well the current shape of the library is generic and kind of low-level. While your proposal sounds like another layer of functionality which could work on top of current library classes and functions. I agree such layer could be part of the library and here are few thoughts about design.

1. It's definitely true that adding more sendControl* methods is not a good way - as it may explode and also some types of commands are definitely bound to the type of control
2. Holding the current state in the memory could be tricky and imply dealing with eventual consistency problems, therefore I wouldn't mess up the DTOs (better name is rather Loxone App model/structure clasess) with such a logic
3. Rather let's add whole new set of classes allowing to hold the state and providing the interaction on the most granular level
   • should be in separate package (or may be separate module in the future)
   • should build on top of the current model classes and Loxone class
   • should prefer decorator pattern (taking the lowlevel classes as arguments rather than extending them)

As stated earlier, the best is to start with prototyping and sharing the code ideas, we could discuss upon.

[TCke83]

I was looking further to start implement this, but i was wondering why the states map in the Control class contains LoxoneUUIDs as value and not a single UUID, are there controls that use this? If i look at the structure file of my miniserver i don't see any state that contains multiple UUIDs. But perhaps there are controls that can have multiple UUIDs for one state key? I don't directly see the fact that multiple UUIDs are possible mentioned in the documentation.

[jimirocks]

Well, not very sure about this - the library has started with Loxone 8 - in that times the documentation wasn't very complete and definitely things have changed. I am only sure there must have been a reason to do it this way - in other words there was some control having multiple UUID per state. Also while for the most controls (may be all nowadays) there is single UUID per state, the LoxoneUuids class does not complicate the life too much - you can just call only().

It might be a good idea to suppose there is alwyas signle value in the newly introduced layer (calling LoxoneUuids.only()) and after some time of real life period, we can either remove the LoxoneUuids or extend the new layr to provide multiple values.

[jimirocks]

ha found an example of multiple states:

loxone-java/src/test/resources/app/LoxAPP3.json

Line 334 in 1ee11dc

"temperatures": [

[TCke83]

Okay, i don't use an intelligent room controller in my current setup, but goot to know it exists, then we should keep the LoxoneUids wrapper to support this.