Project settings - Project generator

The project generator derives a room structure from the group addresses of a project on its own and creates function blocks, visualisation pages and the navigation from it. It works exclusively on the addresses already present - the generator never creates group addresses itself, and it never overwrites any.

The assistant guides you through five steps. What it derives from the addresses is deliberately only a proposal: it is reviewed and adjusted in the third step before anything is created.

Step 1 - Source

Shows how many KNX group addresses the project contains. Internal variables created by function blocks themselves are neither counted nor evaluated later on.

• Create pages: Vertical, horizontal, both - or none. One page per room is created in every selected format; the page formats are taken from the start pages of the project. With "None - function blocks only" just the FB pages with the linked blocks are created. That is the way to go when the room layout of the visualisation is going to be built by hand anyway: wiring the addresses to the blocks is the actual work and it is kept.
• Control elements: block elements or house status elements. The choice only appears when the house status is enabled in the settings. In house status mode the same addresses are placed on the corresponding house status blocks and control elements; a switch is a dimmer there with only the bit address linked.
• Import addresses from ETS: Opens the familiar import for ESF and XML files. If the addresses are already in the project, simply skip this step.

Step 2 - Rule set

The rule set determines how the names of the main, middle and sub groups turn into a structure. It belongs to the project and is stored with it. A set of default rules covering the common naming conventions is included.

Every rule consists of six entries:

• Search in: main group, middle group, sub group, or the bracket text of the sub group. The bracket text is the part in round brackets within an address comment - in practice this is where the spelled-out room or device name is usually found.
• Comparison: contains, starts with, ends with, equals, wildcard, or segment. With the wildcard, the character * stands for any number of characters. Upper and lower case never matter.
• Segment: A special case for names following the scheme "trade.floor.room.device_function". The pattern selects the dot-separated parts. "3" yields "06" for "LDA.EG.06.01_ea", "1-4" yields "LDA.EG.06.01" - the identifier of the individual device. Everything from the underscore onwards belongs to the function and is dropped, as is the bracket text. A range requires at least two segments; it does not apply to a name without any dot.
• Pattern: the text to look for.
• Results in: what the rule determines - see the list below.
• Value: the result. If the field is left empty, the text that was found is used as is - this is how the name of a middle group becomes the room name unchanged.

The available targets under "Results in":

• Floor - the name of the floor.
• Room and Device - the key used for grouping. In the common conventions this is a number taken from the naming scheme ("06") respectively its leading part ("LDA.EG.06.01"). All addresses sharing a key belong to the same room respectively the same device.
• Room name and Device name - the readable name for it. Every address may contribute a suggestion; for each room and each device the most frequent one wins, ties going to the first one found. If no name emerges, the key remains in place.
• Trade and Role - block type and input or output.
• Role is feedback - turns the recognised role into the matching feedback. This makes "_hoehe" in the middle group "Status Storen" the feedback of the height rather than a second travel command. Where a role has no feedback - up/down or a temperature, for instance - the address stays in the tree without a role.
• No name - excludes a text from being used as a name. The same brackets that usually hold the room name often hold a unit or a legend instead ("°C", "0 - off; 1 - on", "100 => closed"). When such a rule matches, the address contributes no name suggestion at all. Rules for the common units and for bracket texts containing a colon, a semicolon or a question mark are included.
• Room suffix - cuts the match out of the room name and turns it into the name of the device. This turns "Kitchen south", "Kitchen west" and "Kitchen north" into a single room "Kitchen" holding three distinguishable blinds. Rules for the points of the compass at the end of a room name are included. The "Search in" field has no effect for this target, because the suffix always works on the room key already determined.

The priority controls the order: the smaller number is applied first. For each target the first match wins. More specific rules therefore need a smaller number than general ones - a rule for "setpoint" has to come before the rule for "value", otherwise the setpoint is recognised as a plain value.

• Restore defaults: Replaces all rules with the supplied ones.
• Export and Import: Saves the rule set to a file and reads it back in. This allows a naming convention set up once to be reused in every further project.

Pattern and value must contain neither the character # nor a line break, because both serve as separators in the stored rule list. Such an entry is reported when you confirm the dialog.

Step 3 - Review and adjust the proposal

The addresses and the rule set produce a tree of floors, rooms, elements and addresses. The "Rule" column shows for every entry which rule created it - this makes it possible to retrace why an address was assigned to a particular room.

This step is mandatory. Nothing is created until the tree is correct.

• Rename: Changes the name of a floor, room or element. The room name later becomes the name of the visualisation page.
• Merge rooms: Combines several selected rooms into one. The elements move into the first selected room.
• Add floor: Creates an additional, empty floor. Rooms can be dragged into it with the mouse.
• Deselect: Every check mark can be removed. Deselected floors, rooms and elements are not created.

Addresses for which no rule matched are not lost: they appear under "Not assigned" and can be dragged into the correct room from there, or deselected. Elements without an assigned block type are shown but cannot be selected.

With very many addresses, the elements of a room are loaded only when the room is expanded. This keeps the tree responsive even in large projects.

Step 4 - Preview

Summarises how many floors, rooms, function blocks and pages will be created, followed by a listing per room. If the project already contains pages with the same room names, this is reported here.

• Create an overview page per floor: Creates a separate overview for each floor containing the rooms of that floor. Without this option a single overview with all rooms is created. A floor holding only one room gets no overview - the start page then leads straight to that room.
• Create start page: Creates a page with links to the floor overviews. A start page already defined in the project is never overwritten.
• Take room names from the room controller: If a room contains a room controller, its plain-text name becomes the room name. The controller belongs to the room and not to a device within it, so the room key "06" becomes the name "Corridor". Rooms without a controller keep their key and are renamed in the tree.
• Do not create empty pages: Rooms in which not a single element is assigned to a block type are passed over. Without this setting, such rooms would produce an empty block page and an empty visualisation page. A floor left without a single room this way does not get an overview page either.
• Skip existing pages: The comparison is made against the pages that existed before the run. On a second run, rooms that already have pages are passed over and listed in the log. If the setting is switched off, the run stops on such an overlap without creating anything.

Step 5 - Create

For every room a page with the function blocks is created, plus one visualisation page per selected orientation holding the control elements, together with header and footer, the overview pages and the navigation. Every control element is linked to its function block, and the group addresses are assigned to the inputs and outputs.

Progress and all messages appear in the log. If a room does not fit on one page, a follow-up page is created automatically.

Every function block carries its address designation as its heading - the device identifier plus the plain text in brackets, for example "LDA.05.01.1 (Entree)". The block therefore shows the same identifier as the group addresses attached to it. Where the installation follows no naming scheme, the block carries the caption of the element instead ("Licht dimmen Küche").

The icon on the left of the header leads one level up: from the room page to the overview of its floor and from there to the start page. Only the topmost page carries no such icon.

If the same room name occurs on several floors - "bathroom" on the ground floor and on the upper floor, for instance - the floor name is put in front of the page name. Without that both would point to pages of the same name and the second room would be lost.

Recommended naming of the group addresses

The generator can only assign what the names contain. The naming below is fully recognised by the supplied default rules. It is not mandatory - every rule can be changed - but it is the shortest path to a proposal that needs no rework.

The scheme in one line

Examples:

• LDA.EG.06.01_ea   ( spots entrance ) - dimmer, ground floor, room 06, first device, on/off. The plain text names the luminaire.
• LDA.05.01.1_ea   ( Entree ) - the same scheme with a floor number instead of an abbreviation. Both are recognised.
• J.OG.12.02_hoehe   ( window south ) - blind, upper floor, room 12, second device, height in percent.
• H.EG.06.01_Istwert   ( corridor ) - room controller of room 06.

The four parts before the underscore are the identifier of the device. All addresses sharing an identifier end up on one block: "_ea", "_dimm" and "_wert" of "LDA.05.03.1" belong to a single luminaire. The abbreviation counts as part of it - "M.05.04.1" (awning) and "JS.05.04.1" (vertical awning) are two different devices even though both carry the number 1. A device therefore has to carry the same abbreviation in all of its addresses; writing "LD" once and "LDA" another time produces two elements.

What belongs where

• Main group = floor. "EG", "OG", "UG", "DG", "2_OG" or spelled out. Central and scene addresses get a main group of their own, for example "Zentral".
• Middle group = trade. "Licht", "Jalousie", "Storen", "Heizung". Feedback may live in a middle group of its own, such as "Status Licht" - that is recognised.
• Sub group = the scheme above. This is where the assignment is decided.
• Plain text in round brackets = name. Depending on the address this is the room or the individual device; which of the two is decided by the generator itself - see "Where the room name comes from".

Abbreviations for the trade

The abbreviation comes first and ends with a dot.

• L, S, NL - switching: switched light, socket, night light
• LD, LDA - dimming light
• J, JS, M, R, RI, RV, B, DF - blind, vertical awning, awning, roller shutter, raffstore inner and outer, shading, roof window
• H - heating and room temperature

Without an abbreviation, the name of the middle group is used instead (Dimm, Jalousie, Storen, Raffstore, Rollo, Markise, Beschattung, Heizung, Licht, Beleuchtung, Steckdose, Schalten).

Endings for the function

The ending follows an underscore at the end of the name, before the bracket text.

• Switching and values: _ea (on/off) or _ein/aus, _wert (brightness in percent), _dimm or _dim (relative dimming - goes into the address tree but has no output on the block)
• Blind: _move (up/down) or _auf/zu, _step or _stop, _hoehe or _position, _winkel or _lamelle, _sperren, _besch (shading)
• Heating: _istwert, _sollwert, _basissollwert, _betriebsart, _stellwert or _stellgroesse, Status Ventil

Feedback addresses

A feedback address is recognised in two ways: by the ending _status, _fb or _rm at the end of the name, or by the address living in a middle group whose name contains "Status" or "Rückmeldung". The generator then turns the function into the matching feedback:

• _ea_status or "_ea" in "Status Licht" - feedback of switching
• _wert_status - feedback of the value
• _hoehe_status or "_hoehe" in "Status Storen" - feedback of the height
• _winkel_status - feedback of the slat angle
• _stellgroesse_status - feedback of the valve

The order within the name matters: the addition belongs after the base function. "_wert_status" is recognised as the feedback of the value, "_status_wert" is not.

Up/down, step/stop and the temperatures have no feedback. Such an address appears in the tree but is not assigned to any input.

Where the room name comes from

In the scheme the room is just a number at first. The generator takes its plain-text name from the round brackets - from all addresses of the room:

• Every bracket text is a suggestion. The most frequent one wins. If room 03 holds "( Küche/Essen )" five times and "( Steckdose )", "( Esstisch )" and "( Decke Cheminee )" once each, the room is called "Küche/Essen" and the remaining texts name the individual devices.
• It therefore pays off to carry the room name on the main functions ("_ea", "_move") and on the feedback addresses, and to name the device only where that is really needed.
• Units and legends in brackets ("°C", "( 0 - off; 1 - on )") do not count.
• If no name emerges, the room controller steps in: a block of the heating trade carrying "_istwert" or "_sollwert" names the room with its bracket text. Without one, the room keeps its number and is named in the proposal tree.
• If two rooms of one floor end up with the same name, the number is appended - two rooms called "Zimmer" become "Zimmer" and "Zimmer 12".

Several identical devices in one room

They are told apart by the device number in the scheme (01, 02, 03). The name of the device comes from the bracket text just like the room name, here from the brackets of this one device. If a point of the compass ends the room name - "Küche Süd", "Küche West" - this becomes one room "Küche" holding two devices that keep the direction in their names.

What does not work

• No abbreviation and no trade in the middle group: the element gets no block type and is not created.
• No recognisable function ending: the address appears in the tree but is not assigned to an input or output.
• Free text without structure ("Licht Wohnzimmer ein"): trade and role are still recognised through the middle group and keywords, but the room only if it is given in brackets.
• Internal addresses with a main group above 31 are always skipped.

Notes

• Existing group addresses are only linked, never changed or overwritten.
• A second run only adds what is missing, provided "Skip existing pages" is switched on.
• The rule set is stored in the project when the assistant is closed, so that a later run builds on it.
• The cleaner the group addresses are named, the better the proposal. The default rules work most reliably when the floor is in the main group, the trade in the middle group and the function in the name of the sub group - and the room name additionally in round brackets in the comment.