Creating KNX Commands in OpenRemote 2.0 Designer
When creating a new command in the OpenRemote 2.0 Designer and KNX protocol is chosen, three properties need to be filled in per command:
Group Address
This is a KNX group address. Use the 'main/middle/sub' naming convention for the group address.
Command
A KNX command name. Currently supported commands are:
| Name | DPT | Description |
| On | 1.001 (Boolean) | KNX Switch On |
| Off | 1.001 (Boolean) | KNX Switch Off |
| Switch On | 1.001 (Boolean) | KNX Switch On |
| Switch Off | 1.001 (Boolean) | KNX Switch Off |
| Status | 1.001 (Boolean) | Read KNX Switch Status |
| Dim Increase | 3.007 (3-Bit Controlled) | KNX Dim Control - increase dimming by maximum step |
| Dim Decrease | 3.007 (3-Bit Controlled) | KNX Dim Control - decrease dimming by maximum step |
| Dim | 5.001 (8-Bit Unsigned) | KNX scale - set new scale value within range [0%..100%] (value derived from UI components) |
| Scale | 5.001 (8-Bit Unsigned) | KNX scale - set new scale value within range [0%..100%] (value derived from UI components) |
More commands will be added during the beta phase. If you have specific requirements regarding a datatype or command you'd like to see included, please let us know on the forums and we can prioritize.
Datapoint Type
KNX datapoint type is currently required. This needs to match the command name given on the previous property.
This requirement for datapoint type may later be removed. Command name would then be implicitly mapped to a DPT as per the table above.
See Also
Comments (2)
Sep 25, 2010
Marc Fleury says:
I think the simplest and foolproof way is to make a drop down menu of the name a...I think the simplest and foolproof way is to make a drop down menu of the name and map everything under it. If you want to point me in the right direction in the designer KNX templates I could take a look at it, shouldn't be too hard.
Oct 08, 2010
Juha Lindfors says:
Drop-downs do need to be added but this change is driven through XML definitions...Drop-downs do need to be added but this change is driven through XML definitions, it is not hard-coded UI.
What I really want to see in the XML schemas is adopting the GWT UIBinder schema that should allow more complicated designs defined where we want them – this requires a GWT update to version 2.0 which we have done but haven't deployed yet, nor have we evaluated yet if there's any issues with using UIBinder schema instead.
An additional point regarding how commands are entered actually drives very deep into the designer tool core – right now all commands are generic without explicit semantic meta-data. This impacts the user interface in terms of what can be assumed and leads to higher complexity.
A very simple metadata description whether a command is a "read" or "write" command already lets the UI reduce complexity by offering commands depending what types of UI components or constructs they are intended for. For specific protocol case like KNX this can be deducted from the command name in the drop-down – which will also imply DPT in case of KNX. DPT in turn can be used to determine whether commands are applicable to switches vs. sliders and so on.
This can then start to lead to improvements in the usability but should be built as generic meta-information to avoid having to deal with each protocol as a separate use case. A simple protocol dialog will then actually have a complex data built behind it.