This document outlines the overall best practice usage guidelines for template and room configuration. These guidelines are aimed at providing guidance to customers on how to best structure their template, room configuration and naming schemes with a view towards optimizing overall Innomesh system management.
Templates
As an overall principle templates are intended to allow for fast and simple deployment of rooms with minimal configuration per room.
With above overall principle in mind the next thing to take into account are the technical limitations that exist with Innomesh and how templates are able to be changed and updated:
- Templates cannot be renamed, meaning once a template is created if you make a change to that naming the only way to move a room between templates is recreation and redeployment.
- When a template is changed those changes are deployed to rooms as follows:
- Space CE — changes are manually pulled into rooms. This is possible to be done en-mass.
- Sight/Pulse — changes can’t be propagated to rooms; they only affect future rooms created with the template.
How a template change reaches existing rooms differs by product:
| Product | Existing rooms | How |
|---|---|---|
| Space CE | Updated | Changes are manually pulled into rooms. Can be done en-mass. |
| Sight / Pulse | Not updated | Changes can’t be propagated; they only affect future rooms created with the template. |
The next and biggest point to consider is your overall system designs and the levels of consistency of those designs. The level of consistency room to room is what dictates which approach best suits your organization.
There are two general concepts for when a new template is required. Selection of which of these template structures to use is dependent upon how many optional features a room design has. An optional feature is generally things like room join capability. Things that are not considered options are changing from one brand of display to another.
With the above in mind here are the two general concepts explained:
Identical Design Template
This is used where a room type is to be deployed on a large scale (typically more than 20 rooms) with identical configuration. The physical AV system will be identical in terms of features (ie. Display, Soundbar, Touch Panel) across all rooms deployed against the template. This archetype allows for the most simplified configuration and deployment.
- Room features that are not used in that room will be disabled.
- Room Options for features that are not used will also be hidden.
- The only individual room configuration required when using this method should be room name, device brand and model and network address details.
Similar Design Template
This is used where a room type is more of a framework. Features that are part of the potential options for a room type will be covered under the one template. This archetype requires a more detailed understanding of the configuration for successful deployment.
- Room Features will be available but disabled in the template configuration where they are part of the overall design concept for the space type. Room options will be enabled to align with those features.
- Features that are not part of the overall design concept for the space type should be disabled from the template and room options.
- When creating a template of this manner a limit of 3 features available but disabled in the template is recommended. This is to help with ease of deployment and complexity when performing regression testing across templates as part of a structured update process.
| Identical Design Template | Similar Design Template | |
|---|---|---|
| Use case | Room type deployed on a large scale (typically more than 20 rooms) with identical configuration | Room type is more of a framework; optional features for the room type are covered under one template |
| Unused features | Disabled | Features part of the design concept: available but disabled. Features not part of the design concept: disabled. |
| Unused options | Hidden | Enabled to align with the available features |
| Per-room configuration | Room name, device brand and model, and network address details only | Requires a more detailed understanding of the configuration |
| Recommended limit | — | Limit of 3 features available but disabled in the template |
Overall the decision of when a new template is required is one that should be carefully considered, with all the factors above taken into account.
Naming Conventions
It is recommended that a naming convention is used for naming of all templates and rooms. The convention should be documented internally for your organisation, detailing the relationship between the name and the attributes origins used to bring the name together.
Template Naming
Template names should be clear and descriptive so that Innomesh users can quickly identify which template should be used for a particular room deployment. The description field should also be used to provide a more detailed description of the template.
Some suggested examples for template naming conventions are the use of abbreviations for a rooms base purpose; MEET for meeting room and TEACH for teaching space combined with other items such as room composition SINGLE for single projection or DUAL for dual projection, where the different elements are separated by a separating character like a dash.
Repeating the same text such as organisation name at the start of template or room names should also be avoided.
The table below shows some examples:
| Purpose | Composition | Features | Template Name | Description |
|---|---|---|---|---|
| MEET | SINGLE | DUALCAM | MEET-COLLAB-DUALCAM | Meeting Room, Single Display, Dual Camera default. Dual camera enabled as default can be downgraded at the room configuration level to a single camera. |
| TEACH | DUAL | JOIN | TEACH-DUAL-JOIN | Teaching Space, Dual Display, Join enabled |
| TEACH | COLLAB | JOIN | TEACH-COLLAB-JOIN | Teaching Space, Collaborative, Join enabled. Collaborative indicates the room is single display, one to all but supports up to 12 displays around the room, ceiling microphones and audience and presenter cameras enabled. |
| HUDDLE | SINGLE | CAMBAR | HUDDLE-SINGLE-CAMBAR | Huddle space, single display with Camera sound bar. Camera Sound bar could be disabled at the room configuration level so that the space is just a single display. |
Room Naming
Room names should be derived from combinations of values such as campus, building and room with separating characters used between those values.
Well structured room naming helps with improved filtering of data and also helps enable the use of features such as Dynamic Hostnames with JSONata.
As room names are unique across a tenancy, it is important to fully qualify the room name. Where there is an “official name” and a “friendly name”, use the official name. In a future update in Innomesh, friendly names will be made available.
Deployment Guides
Deployment guides from a customer environment side are recommended, this should use references from Innomate’s overall deployment guides however as configuration is often specific per customer environment this gives the best chance for internal staff, or contractors to fill in the appropriate fields correctly.
Room Design and Templates
When a system designer is creating a new standard room design, consideration should be taken at the design stage of which Innomesh Template should be used. This should be part of the documentation package provided to the installation and commissioning team so that when a room is deployed the commissioner is clear on which template a room should be deployed with.
Functional Brief
When a system designer is creating a new room design and Innomate’s assistance is requested to either clarify if a new template is required or to create a new template. It is requirement that a Functional Brief is provided to the Innomate and UXT team. This brief should outline the intended functionality of the space and how the room is expected to operate.
A schematic or Bill of Materials alone does not always capture the full intent of a room design. A well-prepared brief ensures the commissioning team has a clear understanding of the expected outcomes, reducing the risk of scope creep and ensuring the room is delivered in line with the designer’s intent.
Consistent Configuration
When configuration for things like DSP files is being generated, it is recommended that all identifiers follow a standardised naming convention. This convention should be understood by the client and confirmed with Innomate to help ensure successful operation.