Nomos Documentation Release 1.1.73

nomos Documentation Release 1.1.73

October 03, 2016 Contents

1 Introduction 2

2 Basic Conﬁguration, Licensing and Control4 2.1 Basic Conﬁguration...... 5 2.2 Licensing...... 16 2.3 Controlling the nomos - Service...... 21 2.4 Scripting Client Tool...... 30

3 The nomos Command Set 53 3.1 Terminology / Types...... 53 3.2 Syntax (Structure of the Protocol)...... 55 3.3 Answering Sequence...... 57 3.4 Formatting Options, Parsing Options, Status Port...... 58 3.5 Command Classes...... 69 3.6 Standard Command Set...... 70 3.7 Dynamic Classes...... 103 3.8 Keyboard Layout (special keys)...... 111

4 Expanded Functions (AddOn’s) 112 4.1 CommandServer Extension...... 114 4.2 GIRA Homserver KO-Gateway, KNXnet/IP Support...... 132 4.3 Event Server...... 147 4.4 Airport Support (Airfoil)...... 152 4.5 eyeTV - Streaming Support...... 153 4.6 Apple Remote Support...... 155 4.7 Sonos Streaming Player Support...... 163 4.8 Z-Wave Support...... 167 4.9 Philips HUE Support...... 174 4.10 mremote Support (commandFusion iViewer support)...... 176

5 Miscellaneous 187 5.1 Working with System Variables...... 187 5.2 Mini- Webserver...... 191 5.3 Timer Support...... 198

i 5.4 Counter Support...... 202 5.5 Logic...... 204 5.6 OSD Keyboard...... 207 5.7 System Recognition in the Network - ZeroConf...... 208 5.8 VPN Access...... 211

6 TABLE of key codes SYSTEM EVENTS 213

7 Workarounds, Previews 215 7.1 DVD Copy Window...... 215 7.2 iTunes Remote...... 216 7.3 Use of the Squeezebox as IR receiver for controlling nomos...... 218 7.4 Useful Shortcuts and Keyboard Commands...... 220 7.5 Special Characters (Mac/Win/VM-Ware)...... 221

8 nomos Cloud API 222 8.1 API Doku General...... 222 8.2 API Befehlssatz...... 228

9 Legal Advisory 230

10 Version History 231

11 Attachments (templates) 232 11.1 {commandserver}.csv...... 232 11.2 {buttons}.csv (Mac only)...... 234 11.3 webserver.csv...... 235 11.4 sysvars.csv...... 237 11.5 timer.csv...... 238 11.6 baos.csv...... 240 11.7 hs.csv...... 241 11.8 knx.csv...... 242 11.9 remote.csv...... 244 11.10 xbmc.csv...... 245 11.11 sonos.csv...... 246 11.12 mremote.csv...... 247 11.13 logic.csv...... 248 11.14 zwave.csv...... 250 11.15 xpl.csv...... 251

ii nomos Documentation, Release 1.1.73

Welcome to the online documentation of the nomos IoT engine The nomos IoT engine, with its TCP-/UDP-Server (Daemon) processing in the background, places at your disposal a way of controlling devices through a network. The software is based on C Code for Linux Systems. A special protocol deﬁned for this application makes possible the execution of a broad range of actions on these systems and their connected devices as well as their comprehensive control through simple LAN or WLAN connections. The nomos protocol serves to unify here the command sets of all the connected devices. nomos system is also distributed under various OEM names. Please be aware that some of the illustrations may not depict the current state of the software and may therefore deviate slightly.

Contents 1 CHAPTER 1

Introduction

We would like to introduce you to the nomos universal automation-software engine capable of controlling devices, regardless of their communication protocols, standards or proprietary software. The innovative nomos IoT software engine acts as the “Swiss army knife” of automation by elevating software and hardware to a single communication layer, creating a seamless automation system that can collect, control and feed from any platform. Meeting the Demand of the Rapidly Growing Automation Market The nomos software is made to adapt easily to new ‘standards’ and is extraordinarily light, weighing in with only 613 KB. Unlike the commonly available point-to-point control solutions, nomos is designed to elevate all software, web-services, building automation systems and multimedia components to just one communication level, delivering the full scope of a centralized controller, including logics, scripts and events. In an OEM environment, this IoT software engine can be deployed on virtually all platforms, including low-power devices, or even embedded in a chipset. A consumer-electronics manufacturer then gains the option of creating interoperability among his own products while also taking control over third-party applications. The nomos IoT software engine unlocks potential for a boundless array of real-world uses. It can also adapt to and learn any individual consumer’s behavior. In a typical “morning routine” scenario, for example, the system knows the user’s personal wake-up preference, timed by wearable technology. It simply activates macros accordingly, switching the Philips HUE scene to ‘energize.’ Then the Sonos automatically initiates a playlist called “Morning Classic”, set at 37% volume level. The Nespresso machine starts brewing the coffee as the TV, also muted, of course, turns on CNN by default. Detecting the last person to leave the house, the nomos system automatically shuts down appliances. In the car, nomos picks up the Spotify playlist, displays the status of the home in a real-time 3D map environment and shows you the way to the nearest electric-vehicle charging station. Upon leaving the ofﬁce, nomos sends your ETA with a push-notiﬁcation to family members or provides details on available parking at your desired destination. – Just one of the many versatile examples, please visit www.nomos-system.com for more IoT use cases. About nomos system

2 nomos Documentation, Release 1.1.73

Founded by home automation veterans as an R&D software lab in 2010, nomos system AG is the leader in innovative building automation, with currently over 2,000 licensed projects and 500 active system integrators in the nomos forum. Using its own software engine, nomos system has completed numerous upscale residential and commercial projects in Europe, the United States and Asia. Suitable for any application from residential to automotive, aviation or marine, nomos system AG supplies OEM partners in the ﬁeld of automation around the globe. To learn more, please visit http://www.nomos-system.com

3 CHAPTER 2

Basic Conﬁguration, Licensing and Control

Available for the basic configuration (network configuration) of the nomos system are appropriate data entry templates. When using Mac systems, you will find that entries mask after the software installation in the system control. When using Linux versions, you obtain the templates for data entries through the Webpanel. Be aware here that the Linux systems have to be licensed before the Webserver will permit a Configuration. The Mac version offers some additional configuration possibilities, such as adjustability of the project path.

4 nomos Documentation, Release 1.1.73

2.1 Basic Conﬁguration

2.1.1 Installation Mac OSX

The preinstalled nomos Linux versions are delivered on corresponding hardware platforms. The Apple OS X version has to be installed by you. You start this Apple OSX installation from nomos with a double-click on the nomos packet:

This step then guides you through the installation:

Click on „Continue“. Read carefully the licensing agreement that appears and then click again on „Continue“. Conﬁrm the query that follows, when you agree to the terms of the license, by clicking on „Agree“. The installation program then shows you that nomos is being installed on the system’s partition. An installation on another partition is prevented by the system. Conﬁrm this with a click on „Continue“. In the window that now appears, please click on „Update“ in order to proceed with the installation. Operator Rights are required for installation of nomos. Please enter the required data:

2.1. Basic Conﬁguration 5 nomos Documentation, Release 1.1.73

Conﬁrm your data entries with „OK“. nomos is now installed. Conﬁrm the completion of the installation with a click on „Close“. Congratulations! nomos is now installed on your system. Please note that the installation of nomos is always referenced to the user. Multiple installations of nomos for various users of one system are not recommended because this may under certain circumstances cause disruptions of functions.

2.1. Basic Conﬁguration 6 nomos Documentation, Release 1.1.73

2.1.2 Conﬁguration Mac

For the conﬁguration of nomos Mac, please open the system settings.

In the window that now appears, please click on „Others“ in the lower portion on the nomos icon:

2.1. Basic Conﬁguration 7 nomos Documentation, Release 1.1.73

You now ﬁnd yourself in the conﬁguration (Preference Pane) of nomos:

Prepared in the field „Configuration“ are all of the network settings required to operate nomos. Changes in the configuration are then permanently stored with a click on „Save & Restart“ and the service is rebooted as circumstances warrant so that the changes in configuration are immediately incorporated. nomos can accept TCP as well as UDP connections. The individual services are activated by placing a Check symbol on them. TCP Port identifies the port at which nomos anticipates the incoming TCP connections. Valid value range: 1024-1038 and 1040-65535. An open connection to a TCP Port has a blocking effect so that no UDP Commands are processed when it is present. UDP Port identifies the port at which nomos awaits UDP packets. Valid value range: 1024-65535 additional dispatching port By activating this option, you are activating additional dispatches of the answer sequence from nomos to the Client on an additional port. This option is intended as a compat- ibility mode for Clients with limited network functionality and should be activated only in case of need. The additional sending port always corresponds to the selected UDP Port+1. UDP Status provides here the IP (broadcast addresses are allowed) and the Port to which the status information about the system will be sent. nomos sends the status information automatically upon changes without a Client needing to query it. Try to use... The standard access to the sysvars.csv can be altered here. When this option is not used, the sysvars.csv is situated at .misc below the project index (default). When in use, the file is found directly in the root of the project index. In addition, the file name can be adjusted. This option is deployed for complex projects to the extent that system variables for the dynamic configuration are also being used. TCP Port 1039 is permanently reserved for Debug and Logging functions and is therefore not selectable. To use this function, please set up an extra TCP connection to nomos on this Port. nomos will then send you information on the processing of Commands received. As many as 16 Clients can simultaneously have access to Port 1039 access.

2.1. Basic Conﬁguration 8 nomos Documentation, Release 1.1.73

2.1.3 Conﬁguration Linux (nomos Box/Pi)

Setup of the nomos Box/Pi Version via Wizard Setup for nomos Box/Pi Version with Console (Terminal)

The nomos Box versions 1:1 are functionally comparable to the functions on the MAC. Exceptions are, of course, the proprietary MAC classes for controlling such internal applications as ITUNES, TV, WINDOW and so forth. In the SYS class, some limitations are also to be considered, such as with SETVOL or SAY or ENABLESS. The nomos Box/Pi systems are designed purely as gateways or as servers for just HTML5 or mremote (CommandFusion). Also supported are, naturally, the CommandFusion GUI Upload and the remote service for AppleTV and the „remote“ iTunes linkup, as well as UPNP and XPL. The nomos Box/Pi HTML5 Service automatically transcodes the GUI Designer project ﬁle on HTML5. Made available in this way on every HTML5-capable Webrowser is the Graphic User Interface. Available at this time are two different hardware variants: nomos Box Hardware: alix3d2 (PC Engines), 1 LAN / 2 miniPCI / LX800 / 256 MB / USB Speciﬁcation: CPU: 500 MHz AMD Geode LX800 DRAM: 256 MB DDR DRAM Storage: CompactFlash socket Power: DC jack or passive POE, min. 7V to max. 20V Three LEDs Expansion: 2 miniPCI slots, LPC bus Connectivity: 1 Ethernet channel (Via VT6105M 10/100) I/O: DB9 serial port, dual USB Board size: 100 x 160 mm - same as WRAP.2E Firmware: tinyBIOS The Box features three status LED‘s on its front: LED 1 - (to the right of the network feed) indicates booting process: LED ON: System boots LED blinks: System started (system loaded Daemon heartbeat recognizable from frequency of blinking) LED 2 - indicates that the NOMOS Service has been started: LED OFF: No Service started (should really never occur) LED ON: Service has started, ready to operate.

2.1. Basic Conﬁguration 9 nomos Documentation, Release 1.1.73

LED 3 - indicates access to external storage (e.g. USB Stick): LED OFF: no access LED ON: read-/write access nomos includes an internal 4GB Industrial NAND Flash Card. The Flash Card cannot be simply exchanged because the hardware ID of the card is required for the license key. The nomos Box has, alongside the network connection jack, an Ethernet connection jack, an RS232 interface and two USB connection jacks on the back. Nevertheless, the nomos Box PoE does not support the usual standard that is used, for example, by the typical PoE switches. In order to use PoE, an optional PoE Injector is required. nomos Pi Hardware: Raspberry Pi Model B Specification: CPU: Broadcom BCM2835 SoC full HD multimedia applications processor DRAM: 512 MB RAM, 400 MHz Storage: SD Memory Card Slot (SDHC), compatible with Class 4 and Class 6 cards Power: 750mA up to 1.2A @ 5V, 5 Status LEDs Board size: 85,60mm x 53,98mm x 17mm The nomos Pi Box has five Status LED‘s on the front: LED 1 - (from the top) read-/write access SD card. Daemon Heartbeat LED flashes: Sys- tem started. System loading is indicated by regular frequecy of blinking. Irregular flashing indicates Read-Write Access on the SD card. LED 2 - (from the top) shows power status: LED ON: Power on. LED 3, 4, 5 - indicate network access LED 3: FDx LED 4: Link LED 5:10/100MBit

2.1. Basic Conﬁguration 10 nomos Documentation, Release 1.1.73

Setup of the nomos Box/Pi Version via Wizard

In order to set up the nomos Box/Pi, the IP address must first be determined. If the IP address is known and the nomos Box/Pi is properly licensed, further configuration can proceed through the R&D Webinterface. There is also the possibility to set up, configure and license the system manually. Basically, the FTP Client is helpful in setting up manually. For that, we recommend, e.g., Filezilla. Proficiency with the FTP Client is a prerequisite. Manual configuration will be explained in more detail later. The nomos Box (Pi excepted) comes equipped with an internal Backup/Restore function. As long as the OS is still running, delivery condition can be reconstituted, except for the license. This possibility will also be treated in greater detail later on. For putting the Box into operation for the first time, a DHCP Server is needed in the network. One learns the assigned IP from the Log of the DHCP Server or from the ZeroConf Protocol (appropriate iPhone App: “ZeroConf Browser” from RemObjects Software). The Box makes itself recognizable through ZeroConf as service “_rmtsysctrl” :

Apart from the IP address, the communications port, service name, version and serial number are also reported by the ZeroConf Service. Alternatively, a running nomos system naturally also recognizes the Box. Observe on the LOG from the nomos Console whether the BOX has been successfully started. Turning on the ﬁlter is helpful here. Other- wise, one can simply reboot the nomos Service: The following report, e.g., appears in the LOG:

2.1. Basic Conﬁguration 11 nomos Documentation, Release 1.1.73

When the IP address is known, access can be gained to the Webinterface of the nomos Box:

On the „Basis Configuration“ page of the R&D Wizard, individual network settings can now be initiated. The Service Ports ( 1037-1039 ) are permanently assigned and cannot be changed at this site, in contrast to the Mac OSX version. The same applies to the use of the project name (nomos). Should you still desire to alter these standard settings, you would have to perform a manual change in the system file nomos.conf. Apart from handling changes or adjustments to the network settings, the R&D Wizard also offers you access to such further services as access to the Software Update Server, the Support Interface (VPN), an entries template for securing or reconstituting the configuration data, password allocation for access to the Wizard and much more.

2.1. Basic Conﬁguration 12 nomos Documentation, Release 1.1.73

The respective applications are self-explanatory and will not be explained further here.

2.1. Basic Conﬁguration 13 nomos Documentation, Release 1.1.73

Setup for nomos Box/Pi Version with Console (Terminal)

Naturally, one can gain access to the Box through the terminal and make adjustments there. Yet, this should only be done by someone who has appropriate experience with the shell. Access to the LOG of the Box can also be obtained through the terminal and direct commands can be launched. For manual conﬁguration, the Box offers two standard services: SSH and FTP. The login and access data for these two services are:

The access data at the moment cannot be changed. The nomos.conf for the manual setup of the system ports and the project name can be found in the index /root/nomos/config and is structured as follows:

- TCP_PORT=1037 - UDP_PORT=1037 - UDP_PORT_ADD=NO - STATUS_PORT=1038 - STATUS_IP=255.255.255.255 - PROJECT=nomos

The terminal linkup with the Box is made as follows: ssh root@[IP address of the Box] opens terminal and ssh establishes connection to the Box. The password challenge is answered with nomos . One arrives directly after this registration in the user index of the Box /root. Not to be confused with the root - index, which is one level higher. Allocation of the IP address: If a ﬁxed permanent IP is desired for the Box, the ﬁle /etc/network/interfaces has to be adjusted: The input: iface eth0 inet dhcp delete or nullify with “#” placed before it The IP information is entered, for example, as follows:

- iface eth0 inet static - address 192.168.1.128 - netmask 255.255.255.0 - broadcast 192.168.1.255 - gateway 192.168.1.1

2.1. Basic Conﬁguration 14 nomos Documentation, Release 1.1.73

Additionally, one should adjust the ﬁle /etc/resolv.conf and, e.g., enter a valid name server (DNS-Server): nameserver 192.168.1.1 For the ﬁxed allocation of the IP address, as also in resetting to DHCP , a Shell Script is also available, which can simply be introduced from a USB stick. The current scripts for this are found in our support forum.

2.1. Basic Conﬁguration 15 nomos Documentation, Release 1.1.73

2.2 Licensing

Loading a license ﬁle Mac Loading a license ﬁle nomos Box/Pi

In order to make the full use of nomos, you will require a licensing file for the specific device. Without a license, nomos presents itself only in the Demo Mode. Full functionality, to include a CommandServer and an Apple Remote Server, is available in the Demo Mode. Beyond that, the presentation is halted randomly every 30 - 50 minutes and must be rebooted again manually. The booting of nomos in the Demo Version is delayed by 30 seconds. During that delay, a display gradually appears. The demonstration version is exclusively available for the Apple OSX versions. nomos is built with modules and can be expanded as desired. The program packet consists of a basic license and the corresponding, optional extentions. At this time, the following modules and system interfaces are available: Basic License Mac: nomos Gate Basic version, not expandable, for users who wish to work with an Apple Computer, for example, as a simple audio player or media client/set-top box. Version contains a CommandServer, a Remote Server, WebServer, simple Button Bar (Standard GUI). This version is also suitable for controlling a simple media center (Frontrow/XBMC, eyeTV, ITunes). nomos Gate plus Basic version, as above, but extendable and contains 10 CommandServers and 3 Remote Server licenses. Packet License nomos Box/Pi: Available at this time for the nomos Box versions are 2 packets (nomos Box - Base and nomos Box - Pro License): nomos Box Base contains 3 CommandServers, 1 Apple Remote Server (ATV/ATV2/Homesharing), mRe- mote Server, HTML5 Server, xPL AddOn, EventServer AddOn, KNX & HS AddOn, UPnP AddOn. nomos Box Pro As with nomos Box Base, but 10 CommandServers, 5 Apple Remote Servers (ATV/ ATV2/Homesharing). Extensions/AddOn’s (only in connection with the Gate plus license): CommandServer AddOn Extension of the CommandServer interface, by respectively 5 protocols (a maximum 25 protocols per system possible). EventServer AddOn Global interface for receiving and analyzing diverse TCP/UDP protocols. (TCP/UDP Listener) Remote Server AddOn Implementation of the Apple Remote Protocol for protocol-based control of iTunes (Mac/Windows), AppleTV. The AddOn is to be licensed for each remote device. Maximum of 25 remote-device connections possible. XPL AddOn Engagement of the xPL Protocol for, e.g., activation of the Logitech Squeeze Box. Extended Buttons AddOn Extended button-bar controlling. (max. 25 button bars definable (GUI Inter- face). Expanded command set for setting up the buttons. Relevant only for Mac systems.

2.2. Licensing 16 nomos Documentation, Release 1.1.73

BAOS/KNX/HS AddOn Building Management Module for the integration of the Weinzierl KNX IP 770 Interface(Objectserver), and/or GIRA Homeserver KO-Gateway, and/or KNXnet/IP (Routing or Tun- neling), and/or the corresponding function protocols Z-Wave and ZigBee. The control of the Phillips HUE is also covered by this license. Streaming AddOn Module for the eyeTV Streaming Service. Streams the current transponder (4 channels) into the network and can, e.g., be received over VLC. UPnP AddOn Module for the activation of the UPnP protocol. This AddOn is needed, for example, when you wish to include a SONOS system. The Streaming AddOn is still undergoing trials and is delivered free of charge and without claim of com- pleteness. m..Remote Server AddOn Communication server for the inclusion of the CommandFusion interface. This module is recommended for each system to which access is to be gained with mobile devices such as iPhone / iPod Touch / iPad. Client licenses: m..Remote Client AddOn End-use device for using the iViewer Client Software of CommandFusion. Li- cense required for each iPhone/iPod Touch/iPad (only usable in connection with the m..Remote Server)

We guarantee Update Service free of charge for at least one year. For OEM customers or purchasers within the scope of an extraordinary licensing agreement, license models or license packets can be generated as desired.

2.2. Licensing 17 nomos Documentation, Release 1.1.73

2.2.1 Loading a license ﬁle Mac

If you lack a valid license file, you can cause nomos to generate the appropriate e-mail. To do this, your e-mail client that is installed on the system has to be correctly configured. Click on „Request Keyfile“. nomos then creates an e-mail message with the system information required for licensing and displays this e-mail message in your E-mail-Client. Should you have further comments pertaining to your request, you may naturally append them and send them off in the e-mail when it is completed. You will promptly receive a response from our Support. Basically required for creating a license is the serial number of the corresponding system. You will find the serial number on the frame or also in the system information. Should you already have a license for nomos, please click on the license file and drag with the depressed mouse clicker to the field „DROP KEYFILE HERE“. This procedure also applies to the m..Remote Client licenses.

Release pressure on the mouse clicker. nomos will now inform you whether the license ﬁle is valid and install the ﬁle as your wish.

Within the ﬁeld for the Keyﬁle is located a small button with a question mark. After clicking on this button, another window appears, presenting information about the currently installed license.

2.2. Licensing 18 nomos Documentation, Release 1.1.73

If a license has a time limit, this information will also be displayed in the same window. You would also ﬁnd in this display in the tab mRemote the correspondingly licensed m..Remote Client Licenses.

2.2.2 Loading a license ﬁle nomos Box/Pi

The license file for the nomos Box/Pi versions can be loaded through the Wizard, if activated. If the Wizard has not yet gone active, the licensing file can also be transmitted through FTP. To request a license file, you will require the serial numbers of the nomos Box/Pi. These are found in the file serial.txt in the index /config, among other places. When you have received a Keyfile, the file has to be stored under the name nomos.key in the index /config. As previously described, this can be done by means of FTP. If the R&D Wizard is active, there will be a dialog there for the licensing. This dialog appears automatically, if no license file is present. The dialog page also contains all the necessary information for registering the nomos Box/Pi. You open the R&D Wizard by entering the IP address of the Box in a Webbrowser.

2.2. Licensing 19 nomos Documentation, Release 1.1.73

There are several available options for receiving the desired license. The buttons „Request Test License“ and „Request License“ are linked with the nomos system Shop. You can request the desired license there. Simply follow the dialog of the Web Shop Systems for this. When you have received your license file, copy the file, for example, onto the Desktop and hit the button „Select file“. Send this now to the license file in the file dialog. After successful transmission, a few seconds may elapse until the file is validated and the license is cleared.

The status of the license can be called up any time with the url http://{IP-Adresse}/licensing.php.

2.2. Licensing 20 nomos Documentation, Release 1.1.73

2.3 Controlling the nomos - Service

The nomos Service, the Daemon (nomos Box/Pi), starts automatically, as long as a valid license ﬁle is present. The Mac OSX Version, however, can be adjusted for whether the Service is supposed to be activated automatically upon login.

2.3.1 Activation of the Service (Mac OS)

To start the Service, click on „Start“‘‘in the nomos system installation in the field „Service Control“. nomos will start up propmptly. If, in this acivated state, the button ‘‘„Save & Restart“ is now hit, the nomos system is automatically started as soon as the user, for whom nomos was installed, checks into the System.

An index for the project data is preinstalled under „Project Path“ after the installation. The individually adjustable path given there to the project index always has to be identiﬁed in full. nomos recognizes a change in the original path and generates an appropriate index structure when the „Save & and Restart“ button is hit.

In the ﬁeld „Service Control“ click on „Stop“. The nomos Service ends promptly and the System entry for automatic Start ( see Control ) is removed. The blue backgrounded portions of the ﬁeld „Service Control“ display in each case the current status of the nomos system.

2.3. Controlling the nomos - Service 21 nomos Documentation, Release 1.1.73

2.3.2 Logging Monitor nomos has a Logging Monitor, which puts out information on the current status of the various services. Mistakes are also posted in the Logging Monitor. You reach the Logging Monitor by pressing the button „Show Log“ on the nomos conﬁguration page:

The Logging Dialog opens. The output corresponds to that of Port 1039. Defective entries in the configuration files, for example, are quickly discovered with this. The Logging Monitor can also make a record of such things and must remain open for this purpose. Furthermore, this monitor’s built-in filtering mecha- nisms considerably simplify a targeted search. A predefined filter can be installed from a pull-down menu. The entry can be overwritten manually, however. All kinds of filter options can be installed with this.

The „Scroll Lock“ button prevents automatic scrolling of entries. The Log continues to be written, however. The content of the Log can be exported into a file. The button „Save Log“ has to be hit for this. This opens a file dialog, where the storage location and name of the Log file can be entered. The button „Clear LOG“ deletes the current content of the window. Logging functions only when the PrefPane is open; the logging sheet itself need not remain open. The logging takes place asynchronously with a buffer of 1000 log lines The LOG can offer helpful information especially upon starting up the system. The so-called initial log provides information about the status of the various modules. When a connection to Port 1039 is established within 10 seconds of startup of the Dämon, the entire log from the start is reported. As many as 16 monitors

2.3. Controlling the nomos - Service 22 nomos Documentation, Release 1.1.73 can be set up at the same time.

Additional Log Output: Log lines with ERROR or WARNING are now presented in red or orange. NOTICE for unused switches/sections in the .csv WARNING for critical conditions that would probably cause a mistake (e.g., lines too long) ERROR for necessary switches that are not present in the .csv Logging can also be called up with NetCat. This can be done locally through a terminal window or for a remote nomos system: after the entry of, e.g., the command in the terminal window: nc 10.8.0.48 1039 opens a NetCat connection on Port 1039 with the IP address 10.8.0.48

2.3. Controlling the nomos - Service 23 nomos Documentation, Release 1.1.73

appropriate output appears. The display can be ended with “Control C”. The Wizard of the nomos Box versions also has a Log window. The Log window of the Wizard runs of its own accord. Therefore, parallel with the display in the log window, you can also make changes and settings on the Wizard.

You can also execute commands in the log window directly. Press the button „Execute command“ for this. Enter your desired Kommando sequence in the following dialog window and then press the Send button.

2.3. Controlling the nomos - Service 24 nomos Documentation, Release 1.1.73

You can follow the executed command sequence and possible response sequences directly in the LOG window.

2.3. Controlling the nomos - Service 25 nomos Documentation, Release 1.1.73

2.3.3 The nomos Directory Structure

The nomos directory structure is permanently established, except for the origin of a directory. As previously described, this is automatically anchored with the installation of the Service or with a chang in the prescribed path. We will now discuss the particular folders within the project structure. The tree shows the directories below the directory origin. In this case the origin is „nomos“. This can, as already mentioned, by changed at will.

The directory structure for the Linux-based systems is identical to the directory structure of the Mac Systems. Only the Start directory /projects here cannot be changed. The path /projects/nomos is set according to the standard and can, at the moment, be changed only in the file /config/nomos.conf. The Linux versions have a so-called Config-Watch function as well. The /config folder (with nomos.conf, nomos.key and so forth) is under permanent surveillance. As soon as a file in it is changed, generated or deleted, the nomos Daemon is automatically started anew. The various .csv files are not automatically generated and should show up only where the respective files are to be found. Folders that are added thereafter, for example, for template files are possible and in no way affect functionality. With alterations of the project path, the settings become active only after the “Save & Restart“ button is hit., Directory Structure

/[PROJECT]/addons CommandServer Files /[PROJECT]/events EventServer Files /[PROJECT]/gui Button Bar Files /[PROJECT]/misc PlugIn’s and System Files /[PROJECT]/misc/mremote/ mremote (GUI-Designer) Project Directory /[PROJECT]/misc/web/ Image folder for the Webserver /[PROJECT]/misc/baos.csv BAOS configuration /[PROJECT]/misc/hs.csv GIRA Homeserver configuration /[PROJECT]/misc/knx.csv KNXnet/IP configuration OPC Export File (Default Name) belonging to /[PROJECT]/misc/knx.esf KNX /[PROJECT]/misc/logic.csv Logic Definitions

mremote Configuration /[PROJECT]/misc/mremote.csv /[PROJECT]/misc/remote.csv Apple Remote Definition /[PROJECT]/misc/sonos.csv Sonos Player Definition /[PROJECT]/misc/xbmx.csv XBMC Player Definition /[PROJECT]/misc/sysvars.csv System Variables /[PROJECT]/misc/timer.csv Timer Configuration

Webserver Conﬁguration /[PROJECT]/misc/webserver.csv

2.3. Controlling the nomos - Service 26 nomos Documentation, Release 1.1.73

/[PROJECT]/misc/zwave.csv Z-Wave Conﬁguration /[PROJECT]/scripts Directory of Script Files /[PROJECT]/XPL Directory of the xPL Conﬁguration

You will discovered in subsequent chapters how the files we just named are individually structured. The absence of certain files in the overall structure presents no problem. In this case the interfaces belonging to them are deactivated. There is also no problem with docking additional folders, for example, for model files. Additionally, a referral to a project-wide sysvar.csv has been installed for complex installations. If this function is used, the standard sysvars.csv in the ./misc index is ignored and shunted to a file installed here. An more detailed explanation of this function can be found in the Chapter: Working with System Variables.

2.3. Controlling the nomos - Service 27 nomos Documentation, Release 1.1.73

2.3.4 The nomos Firewall

For additional security and protection against abuse, nomos has been equipped with its own Firewall. The Firewall is only available at the moment for the Apple OS X versions.:

This Firewall only protects against the execution of protocol instructions that are supposed to be blocked on the targeted system. One should be congiszant that, when the ports are open, for example, to gain interactive access to the Internet, codes are also transmitted to the system and can be executed through script instructions. Commands such as SHUTDOWN or SLEEP can also be an annoyance for certain target systems.

All commands of all classes, including the commands from the included AddOns (Command – Server), are available for the firewall. Appended values are not taken into consideration. The erection of the firewall is quite easy. Appropriate selection buttons are at your disposal for the class and for the commands. A command to be ignored is selected simply in this way. Chosen commands are marked with a check symbol and can also be removed again selectively. The selected commands of one class and those to be ignored are placed on display in the overview window. By selecting , all the commands of a class can be marked, while the selection deactivates all commands of a class. In the example above one observes that the commands RUNAS and RUNSS from the class SCRIPT, as well as the commands RESTART, SHUTDOWN and SLEEP from the class SYS in the firewall are activated and are ignored by the nomos system. These settings apply respectively only to the target system, where the firewall has been erected. With several nomos systems in the network, therefore, the settings must be made for each system.

2.3. Controlling the nomos - Service 28 nomos Documentation, Release 1.1.73

The Firewall conﬁguration is read only when nomos is started. When Commands/Classes are blocked, this is noted in the Log . The changes are not stored until the SAVE button is pressed. Changes that are not stored are lost only when the PrefPane is closed. Changes to the ﬁrewall settings only become active upon restarting Service. CommandServer classes are read as known to the system. When new CommandServer classes are integrated, the PrefPane must also be closed and then opened again, since the reading of classes happens only once at the opening of the PrefPane.

2.3. Controlling the nomos - Service 29 nomos Documentation, Release 1.1.73

2.4 Scripting Client Tool

The Scripting Client Tool is a handy utility that should help with the employment of the nomos system. The command sequences for control can be put together with this tool in a simple way. Command chains can also be laid down as Script. Diverse Logging/Monitoring functions assist in ferreting out possible problems. The tool is continually being reﬁned and extended with additional utilities. This documentation will not be continually revised, however. Additional functions should be self-explanatory in the Client – Tool. The tool is available for Windows and Mac OS.

2.4. Scripting Client Tool 30 nomos Documentation, Release 1.1.73

2.4.1 Installation Windows

Open the ﬁle Setup.exe to install the software. A window for installation of the application will then appear.

Now select your target index for the program installation or follow the path suggested. Confirm the dialog with „Continue“. In the ensuing dialog, please read the licensing terms and affirm them. After you have confirmed the dialog with „Continue“, the software will be installed.

2.4. Scripting Client Tool 31 nomos Documentation, Release 1.1.73

2.4.2 Installation of the LabVIEW Runtime Environment Windows

The software was developed under LabVIEW. Therefore, the LabVIEW Runtime environment has to be installed. Users who already have LabVIEW Runtime environment installed on their systems, can skip the following steps and abort the installation routine. Following successful installation, you will automatically be prompted to install the LabVIEW Runtime environment.

Please conﬁrm the unpacking of the Archive ﬁle.

Acknowledge the dialog with „Unzip“. The installation ﬁles will be unpacked in a temporary index and the installation is started upon conﬁrming the following dialog.

2.4. Scripting Client Tool 32 nomos Documentation, Release 1.1.73

Please conﬁrm this dialog as well with „Next“ and accept the licensing agreement in the following dialog. Conﬁrm all dialogs that follow with „Next“. Following succesful installation, a corresponding notice appears whereupon you will have to reboot your system. Following a successful new-start, the nomos Scripting Client is ready to operate.

2.4. Scripting Client Tool 33 nomos Documentation, Release 1.1.73

2.4.3 Installation Mac

For installation on the Apple OSX system (from Version 10.6), please open the installation package nomos Client.pkg

This opens the installation dialog, which you then follow along and carry out.

Upon successful installation, you will ﬁnd the nomos.app ﬁle in your Applications folder.

The nomos ScriptClient can also be employed without going through the installation routine. In this case, copy the file manually into the application folder and start die application. When the application is being carried out for the first time on a Mac system, or if no LabVIEW Runtime Version is present, you will receive a notification to that effect.

2.4. Scripting Client Tool 34 nomos Documentation, Release 1.1.73

Confirm the notification in the window by clicking on the Download Button. You are then directed to a Website of National Instruments, where you can load the Runtime Version. You will also find the relevant installation instructions there. Following installation of the Runtime Version, you can use the application.

2.4. Scripting Client Tool 35 nomos Documentation, Release 1.1.73

2.4.4 Application

The nomos Scripting Client serves for the simple generation of command sequences (Script´s),‘which can be created with this tool and tested. Furthermore, the generated Script´s can be deposited in an internal databank. Uploading of the Script ﬁles to your nomos system can also be accomplished with this tool. Also built in is a simple interface, which makes possible a simple implementation of new command sets for later versions. Monitoring funktionalities are integrated into the nomos Scripting Client as a managerial control mecha- nism. This makes possible an overview of all communications. Detailed information can be found in the Chapter: Monitoring. Start the nomos Scripting Client with a double-click on the program icon:

The following program window appears. (Windows: A corresponding entry can also be found in the Start Menu - Mac: The ﬁle nomos.app is found in the program folder)

2.4. Scripting Client Tool 36 nomos Documentation, Release 1.1.73

When all the previous steps have been taken successfully, you can then establish a connection with your nomosSystem. Enter for this the IP address and the corresponding Port (Standard setting is 1037). You may choose between TCP and UDP (Standard) connection. Be aware here that the settings made also conform to your nomos system. When you have entered all the data, press the button Connect. The software takes note of all IP addresses with which a successful connection can be set up. Should you wish to remove an entry from the list, selected that entry on the list, position the mouse cursor over the IP address entry and press the right mouse clicker. A context menu appears with the content „Remove Address“. Highlight the entry in the context menu with the mouse pointer and hit the left mouse clicker to conﬁrm.

Once a connection has been established, a status display will conﬁrm this. Also displayed will be the currently installed nomos version of the connected system as well as its MAC address. In the Monitoring Window you can observe the data exchange.

2.4. Scripting Client Tool 37 nomos Documentation, Release 1.1.73

Following the establishment of communications, the nomos ScriptingClient calls for the current program version of the associated nomos system with the command chains , and with the list of the Script files stored on combined system. More about this is explained later in this document. Information on the installed license and the MAC address of the associated Apple system is also displayed. Notice: The Scripting Client activates itself upon a confirmed connection with the nomos Service. Without a confirmed connection the Scripting Client cannot send any TCP/UDP packets.

2.4. Scripting Client Tool 38 nomos Documentation, Release 1.1.73

2.4.5 Working with the ScriptingClient

After you have succeeded in setting up the connection to your nomos system, you can now begin to send commands to the nomos system. Always make use of a plausible chain of commands for this and take care that the commands are processed sequentially. This means that you may have to turn on a device first before it can take further commands. Proceed here exactly as you would, for example, when working with your local applications on an Apple Computer or some external device like a TV set by means of remote control. Illustrated in the following example is the control of the eyeTV application with an Apple Computer. More detailled description of the possible commands and their functions can be found in Chapter Command Set. The nomos Command Set is divided into classes (Device), the class command (Code) and a possible value (Exception) to be transmitted. The characteristics specific to code or the structure required by the sequence to be sent on is handled for you entirely by the Scripting Client. You merely need to choose from the selection fields and append them to sequence. Now, in order to open the application eyeTV, you select the class (Device) as follows.

Following the selection of the class, you can cause the available class commands to be displayed and then choose the desired command. The opening of an application basically takes place with the ON command. When the application has already been opened, the ON command has no further effect.

2.4. Scripting Client Tool 39 nomos Documentation, Release 1.1.73

After having chosen the class (Device) as well as the command (Code), you press the button „add“. In the „String to send“ display now appears the complete command that is sent to the nomos Service.

Now, press the „send“ button in order to send this string to the nomos System. The eye TV application then starts on the Apple Computer, if this had been installed. If your system was set up without TV reception, you would send some other class, e.g. or . After the command string is sent, the successful communication is displayed in the monitoring window. nomos responds to each command with „|OK“. If a command cannot be interpreted, the response „|NOK“ will appear.

An extended logging function is also provided and will be described in detail in the documentation that follows.

When you pass the mouse pointer over the current command, a tool tip appears with a notice of which function the command contains. You will see that further settings are necessary in order to take the application to the desired status. Normally, the applications do not always open in full-screen mode on the Apple Computer, as desired, for example, with the TV or DVD replay. Furthermore, additional settings are needed, like a possible predesignation of the sound volume, the program selection or the closing of a previously engaged application. In the following example, we will lead you through the previously explained command so that the appropriate TV application in full-screen mode starts with the deﬁned sound volume and the deﬁned channel selction. In the succession of commands, please proceed just as you would with the settings for local manipulation on the Apple Computer.

Starting position is our string: We now expand this string by the command FSON (full-screen mode).

2.4. Scripting Client Tool 40 nomos Documentation, Release 1.1.73

Select the appropriate Device and Code, and press the add- button. Please take care that the selected commands are always added at the end of the command string. If the string is attached at some other position, please mark that position with the mouse pointer in the “string to send” before pressing the add-button and conﬁrm the position with a click on the left mouse key. Then press the add-button and the command inserts itself at the selected position in the „String to send“. Please take care that the position of insertion is now internally “acknowledged”. This means that all further commands will line up behind the command that was inserted last, until you change the insertion position again, as previously described. You can also change this string manually, as well as delete or augment entries or value content. After you have hit the „add“ button, the string should look like this:

Or when using iTunes try this:

We now expand the string with a preselection of channels. Without such channel assignment, eyeTV basically starts on the channel that was used last. In the commands (Code) of the class (Device) , you choose the command CH#. When a command ends with the special character „#“ , this means that an additional value is anticipated, which then has to be entered under „Exception“. The entry ﬁeld will be activated appropriately. The value that is anticipated is displayed behind „Exception“ . For the command CH , this is a value between 1 and the maximum number of TV programs made available on eyeTV.

Now enter the value of your selection in the ﬁeld „Exception“ and press the add-Button. Thereafter the string should look like this:

For iTunes, make use of the PLAYPLAYLIST command in order to begin the selection of a Playlist:

You may send the string off again and again in order to observe the effects on the Apple Computer. You will also notice that command strings sent more than once have no effect on the running system. If the your application „eyeTV“ or „iTUNES“ had been closed before the string is sent off, the application will merely open the ﬁrst time you send the string. This is because the application is only ready to receive when it has been completely started and therefore ready for reception. That takes, as a rule, a few seconds. Nevertheless, nomos Service has already sent the attached commands to the application. Since the application was not yet “ready”, the commands went off into the blue. Here you have the option to deliberately delay the execution of the commands. This will be explained more precisely later. In the next step, you may now extend the command set to include the system volume at which the application is supposed to start. Now select for this the command VOLSET in the class SYS. This command again

2.4. Scripting Client Tool 41 nomos Documentation, Release 1.1.73 anticipates an additional value (Exception). Enter in the ﬁeld the desired value between 0 and 100. After hitting the „add“ key, the string should look as follows:

appropriate for iTunes:

It is immaterial at which position the chain of characters now appears, since this has no effect on the result, whether or not you have made a change to the sound volume before opening or after opening the application. One can now still complete the string in which one would engage such eventualities as an activation of the screen saver or an earlier „Muten“ (muting) of the eyeTV application and extend this with appropriate removal commands. For that you choose the command DISABLESS in the system class SYS , press the add-button, select the command MUTEOFF from the choices on offer from the class TV and press the add-button again The string should now look like this:

appropriate for iTunes:

When you send this command to the Apple Computer now, the application starts accordingly in the full- screen mode, with the channel preselection of 3, with a system loudness of 30%. A screen saver that may have been active is deactivated as is any previous mute application. Now you can lay down the whole command chain as script on the Apple Computer or stow it in the internal Script datenbank. Please proceed here as follows: Select the card „Script Data“ from the register selection of the Scripting Client

2.4. Scripting Client Tool 42 nomos Documentation, Release 1.1.73

In the lefthand portion of the card you will find the Script – Files in the internal Script Datenbank and in the righhand portion of the card you will find the scripts that can be executed, namely those you had stored on the system. If you would now desired to store the string as Script, press the button „New“ and enter a name for the Script file (typically TVon or iTunesON). The file ending (Suffix) is handled automatically and is already fixed with the designation .myh. If the Script file is already stored on the system, it will be appropriately displayed in the righhand selection table. Scripts can be loaded for processing any time in the „String to send“ window. For that you would mark the corresponding script file with a mouse click and then hit the „Load“ button. Should you wish to delete the selected script, press the „Del“ button and when you are ready to execute (for this the Script has to be present in the system), hit the „Run“ button.

The Scripts basically should also always be stored in the internal Script DB. You may dock or choose several internal databanks. The datenbank ScriptDB.sdb is the default databank that is normally opened at program start. The docking of, for example, project-speciﬁc databanks is recommended. Later versions support direct copying of databank content to the system. Scripts may also be started, however, with the class appropriate for iTunes:

Now send the string to the Apple Computer and you will see that the TV application with the desired or preselected program or the iTunes application with the desired playlist now opens. You may transmit as many arguments as you please. Should you now wish to preset the sound volume, the following change is necessary. Again change your script ﬁle as follows:

2.4. Scripting Client Tool 44 nomos Documentation, Release 1.1.73

appropriate for iTunes:

File up the Script ﬁle to storage, for example, under the names TVon(CH,VOL).myh or under iTunesON(CH,VOL).myh and generate the Call Code:

or correspondingly:

Change the auguments as you see fit and send the string again. You will see that the volume can now also be set next to the program position. You may use whatever arguments you please. Arguments can also be deployed in lieu of URLs, ímage paths, music titles, window sizes or even codes or classes. The argument replaces or complements a Kom- mando line by its respective value content or text before the call is processed. Arguments can also be fulfilled globally.

A Script with the content <[ARG]> can be globally fulﬁlled with the use of the transferral command GARG . The following call would ﬁll all wild cards with the transferred value:

ARG= and GARG= can also be used in combination. To be noted here is that ARG= has to be used first in order to fill targeted placeholders. With the subsequent employment of ‘ :txt-command:‘GARG= all the rest of the wild cards are filled.

<[ARG]> The Script can be processed appropriately with the following call:

Filled out accordingly were the ﬁrst ARG with „3“, the second ARG with „50“ and the third and fourth ARG with „ITUNES“, thus presented as follows. (Processing of the arguments always takes place sequentially.):

In essence you have now grasped the principle of the ScriptingClient. It would be a good idea to test the various commands one after another in order to become familiar with their effects in controlling the nomos system. Naturally the script files can also be made up by hand and laid away in the directory .\scripts. The .myh files are simple ASCII files that can be prepared and processed with any text editor.

2.4. Scripting Client Tool 45 nomos Documentation, Release 1.1.73

2.4.6 Scripts and their uses

As already described, Scripts define an an entire functional process by stringing individual commands together in a row. The employment of Scripts considerably simplifies the configuration of a nomos system. Furthermore, no reset has to be carried out during running time in order to change a script definition, because a script that is to be carried out is always read in anew. Dynamic content can also be transmitted with a Script Call. We basically prefer the employment of script calls rather than the employment of pure command chains as described in the configuration files that follow. Naturally, „Script in Script“ calls can also be carried out. To be noted here is that delays may occur through the sequential processing.

Example:

Script0.myh with content:

Execution would be initiated with the following command:

Executed one after another accordingly would be Script1.myh through Script3.myh. The execution then progresses, depending upon the content of each particular script, as long as the running script is being processed.

A parallel processing can be forced by means of the command FORCERUN . The script is read in with this and processed in its own thread:

The call by means of command would now be read into all three script ﬁles and deposited in its own thread for parallel execution. Reserved Script Names: An additional feature is the so-called reserve scripts. These are automatically carried out if they are present. With these scripts, you can inﬂuence, among other things, the booting behavior of nomos. init.myh The content of the scripts is executed after a Service startup. exit.myh The content of the script is carried out before the Service is ended sleep.myh The content of the script is activated before the Standby function wakeup.myh The content of the script is carried out after the „Wakeup“ Some examples of the use of these reserved scripts follows: The init.myh Script:

2.4. Scripting Client Tool 46 nomos Documentation, Release 1.1.73

This script, if it is present, and the nomos Service was conﬁgured on “autostart”, is executed automatically after starting up the system. With appropriate calls within the script, for example, applications can be automatically started, „Welcome Messages“ caused to display, or such parameters as System- and/or Application sound volume preprogrammed. The connected TV or Audio System, for example, can also be automatically turned on at the starting of the system. Das exit.myh Script: executed when the running nomos Service is ended. This applies also when the nomos system is being shut down with the system steering. Turn-off commands for the extended periphery, e.g., the TV or Audio system, can be laid down here, for example.

2.4. Scripting Client Tool 47 nomos Documentation, Release 1.1.73

2.4.7 Broadcast Monitoring

The nomos Scripting Client, along with the Monitoring Window already mentioned, also possesses a Broad- cast Monitor and a System-Log Monitor. The Broadcast Monitor serves to display the reports that nomos sends along to the network through the Broadcast Status Port. To start the Broadcast Monitor, switch to the ﬁling card „BC Monitor“.

Hit the „Start“ button and change, for example, the sound volume with your keyboard. You will immediately receive a Feedback Message with the corresponding current values. nomos also sends information on the currently running music titles or the TV program that is currently on. The PLAYER STATUS of the respective applications is also transmitted; for iTunes typically a PLAYED or PAUSED. Broadcast status reports can be received and analyzed with the Eventserver in order to trigger other appropriate actions. The Eventserver will be described in more detail later in this material. System Monitor Other monitoring windows open by pressing the „Monitor n“ keys.

This is the system monitor, which delivers information on whatever nomos Service is processing. This monitor serves, for example, for the analysis whenever problems crop up and can reveal implausible behavior. The sending sequences can also be observed by using the CommandServer- function. The Monitor has to be started by pressing the Logging buttons. The Port 1039 is permanently set and cannot be changed.

2.4. Scripting Client Tool 48 nomos Documentation, Release 1.1.73

The Monitor has some filter functions that somewhat simplify handling. Several filter functions can also be entered. A semicolon has to be used here as a separation character for the individual filters.

The Log can also be exported into a ﬁle and respective LOG ﬁles also imported again. Use this logging function primarily to observe the Startlog. The start sequence is buffered around 30 seconds after the start of Services and reported entirely upon opening of Port 1039. It can be seen in the Startlog whether all modules have properly started or whether errors have occurred

2.4. Scripting Client Tool 49 nomos Documentation, Release 1.1.73

2.4.8 Testing Field

In order to test basic control functions quickly, a small testing field was integrated into the ScriptingClient. You will find the testing field under the filing card „Test“

The buttons are preallocated with specific system functions. As soon as a client connects his nomos system, the functions can be carried out. Free command chains can be sent to the system on the field „Free String to send“. You can learn the functions of the various buttons from the instructional strip (Tipstrip/ Mouseover). Use the „Free String to send“ in order, for example, to park frequently employed command chains or script calls. You will find a further aid, the QuickPanel, under filing card „Tools“.

Another dialog window opens. Here you can lay down as many Kommando sequences as you like, store them as in a ready room and also read them in again. To read in the .qp file, it suffices to pull the file over the nomos Logo (Drag&Drop)

2.4. Scripting Client Tool 50 nomos Documentation, Release 1.1.73

The Kommando sequences can be pulled with the Drag&Drop function from the main dialog window directly onto the Quick Panel. Files may also be acquired from the main application by pressing the „–>” button.

2.4. Scripting Client Tool 51 nomos Documentation, Release 1.1.73

2.4.9 Other Functions

You will find other functions in the file dialog of the nomos ScriptingClient. Along with the loading of the Script-DB, this also contains a function to update the command set as well as the callup of the Command- Server definitions (AddOn) that will eventually be present.

As soon as your system possesses the corresponding definitions table, the command set is extended with the call on the data. Instructions on the CommandServer- files are found later in this material. With the function „Command Set load“, you can read in the current command set from the definitions file CommandList.csv. You can find the most current definitions file on our Webseite www.nomos- system.com

2.4. Scripting Client Tool 52 CHAPTER 3

The nomos Command Set

After the start of the nomos system, nomos links up the ports defined in configuration to all the network interfaces in the system and waits for an incoming connection. When nomos receives a command that corresponds to the defined command set and presents a valid Syntax, it carries out this command and reports the successful execution and, depending upon the circumstances, any occuring response values back to the Client that initiated the callup. Communication among all connected systems takes place herewith through a uniform and seamless command structure, the nomos system Protocol. Depending upon the type of command, all sorts of different actions are induced this way in the system. The scope of such actions ranges from simple ones confined to the system’s local user interface all the way to the complete shutdown and rebooting of the system. The nomos system also offers the possibility to play out locally various scripts and command sequences and to carry them out, if desired, fully automatically.

3.1 Terminology / Types

The command set of nomos - Software is divided into two types of command

3.1.1 Classes (CLASS)

Classes <{CLASS}> are there to tell nomos which types of command should be executed. The set of commands that is supported is also kept in a structured, comprehensible framework in this way. Furthermore, callups of classes must always be terminated with (see Structure), so that a safeguard is simultaneously established with this procedure against unintentional disruptions in connection and incomplete sequences. The callup of a class in the nomos system does not carry out any commands.

53 nomos Documentation, Release 1.1.73

3.1.2 Commands (CMD)

<{CMD}> put the actual set of commands of the nomos system at your disposal. Commands can come alone or augmented by arguments.

3.1.3 Scripts

A script is a chain of commands that is available as a function that can be called up (Macros). Any number of scripts can be generated and called up. Furthermore, as many as 10 different arguments can be transferred to the script upon callup. A script can be written, changed or deleted with the program during the running time.

3.1.4 Special Commands

Special Commands, e.g. , are independant of classes and can be included at any desired position in the sequence. The rules of syntax apply to the standard commands. We recommand, however, that special commands be employed outside of any class or directly following a class termination ().

3.1.5 Formatting options (optional)

Formatting options can be added to their respective commands as an option. Output can be inﬂuenced at will through corresponding format strings. Search and sort functions can be initiated in this way.

3.1.6 Protocol Converters or Conversion Options (optional)

Conversion options are employed as options to inﬂuence arguments, to recompute them or to transform them.

3.1. Terminology / Types 54 nomos Documentation, Release 1.1.73

3.2 Syntax (Structure of the Protocol)

Array Processing

The syntax for a valid command without argument Example:

The command sequence for a command with argument, where ARG stands for the kommando-dependent argument to be employed. Example:

The command sequence for a command Formatting options: where the optional {FORMATSTRING} stands for the corresponding expression to be deployed. Example:

The command sequence for a command with argument and conversion options: where the optional {CONVERTERSTRING} stands for the corresponding expression to be employed. Formatting and conversion options can also ﬁnd application within a command at the same time. Example:

...... Commands can be lined up in series so that an unbroken command sequence results. Example:

<.....> Different classes can be combined in one sequence in the same way. Example:

> The sending of sequences nested in one another is also possible.

1Byte Hex values can also be incorporated into the command sequence. Invisible characters, for example, can be transmitted with this as well. The transferred values are transformed into the corresponding decimal numbers. Hexadecimal values are distinguished by a „\0x“ in front of them.

3.2. Syntax (Structure of the Protocol) 55 nomos Documentation, Release 1.1.73

Example: writes a two-line text in the main button bar.

The maximum length of a command sequence amounts to 8192 Byte (sign). If a class has not been terminated, all of the commands contained in this class callup are discarded.

3.2.1 Array Processing

The nomos system protocol also supports Arrays. For example, lists can be used for them. An Array is deﬁned by means of a separation mark „|“. It is also possible, for example, to generate multiple queries in this way. If such a list is transmitted as argument to a Kommando, for example, elements of the list are processed in the order encountered and a corresponding response sequence is generated. This behavior is comparable to a „FOR-loop“, as is known from applied computer science.

Example: As answer-string, the following output, e.g., would be generated: GETIDTITLE=One Of The Brightest Stars|OK

If a list with several titles like this one is then transmitted:

The nomos system analyzes the transmitted list into its discrete elements and executes a corresponding GETIDALBUM for each element. The result is a reconstituted list that is reported back.

3.2. Syntax (Structure of the Protocol) 56 nomos Documentation, Release 1.1.73

3.3 Answering Sequence

The answering sequence of the nomos - System consists of a repetition of the command sequence. Argu- ments are not repeated. For the sake of XML compatability, the comprehensive „<“ and „>“ is dispensed with in the commands. Several commands of the same class are separated with „|“. Commands with a valid syntax are always marked with the Argument „OK“ in the answering sequence, while invalid commands get „NOK“:

CMD1=OK|CMD2=NOK In the example above, CMD1 was a valid command; CMD2 was invalid.

If the answer to a command contains an Argument (ARG), that argument is initially included behind the command: CMD=ARG|OK

This behavior is characteristic of the employment of format options as well. The parameters are also added to the answering sequence: CMD{FORMATSTRING}=ARG|OK The maximum length of an answering sequence can amount to 8129 Byte (sign).

3.3. Answering Sequence 57 nomos Documentation, Release 1.1.73

3.4 Formatting Options, Parsing Options, Status Port

In the following we described placeholders used for such diverse functionalities as initiating queries with formatted output, utilizing or parsing of textual information and transmitting information. Format options/Conversion options always refer here to the partial argument that precedes them.

3.4.1 Formatting Options

Deployment of formatting options that force formatted response values. This is needed, for example, to re- format Time Tickers, which return values in seconds, to give back minutes and hours automatically. Speciﬁc list outputs can also be generated with this. It is necessary, for example, in order to query iTunes playlists. The option is attached inside „{}“ to the command for which the response value is to be analyzed. Currently available are the following formatting options:

%h recalculates a value in full hours %m recalculates the value in full minutes %s represents the Value 1:1 %l (List) initiates indicated output after „Index“ ; „Length“ (Count) counts the elements of a list (should be positioned at the end of %lc the option chain) %ls (Sort) sorts a list alphabetically %lf (Filter) ﬁlters the output of the list %lu (Unique) ﬁlters out all elements present more than one time %c (Partial string) outputs a partial string %r (Replace) replaces one character chain with a new one %t Dummy, in order, e.g., to “name” list outputs (Tagging) %fxml Formatting command for xml-Content (see below)

Formatting options can be combined or linked together as desired. In so doing, the formatting options are separated by commas, {%lfa,%ls ,%lc} (generates a list whose elements begin with „a“ and sorts the elemente alphabetically, placing the sum of all elements atop the list). Please keep in mind here that the options are applied one after another in that order. Thus the filtering should take place, of course, before the count is sent back. Employment of various Options: Forcing output in digits: %3m commands response with at least 3 digits and positions BLANKs (empty spaces) in front Constrains and zeroizes with left-hand zeroes: %04s commands at least 4 places and fills them with left-hand zeros Specified output of lists (possible with all commands that return lists):

3.4. Formatting Options, Parsing Options, Status Port 58 nomos Documentation, Release 1.1.73

%l{Index},{Length} gives back {Index} {Length} list elements. Where {Length} is negative, the count runs backwards, namely the output is turned around %lc adds onto the list output the number of elements contained in the format „...=({Number})|..“

%ls sorts the list output alphabetically %lf{Searchstring} filters the list output by content of {Searchstring} . The search here takes place from left to right. %lu ignores elements of the list that are returned multiple times Universal Format String: %c{Index},{Length} gives back certain characters of a string. %r{String A},{String B} replaces or deletes characters from {String A} through {String B}. If {String B} is empty or if no argument hs been given, all characters of {String B} are erased. The two formatting options may be positioned anywhere as desired. Formatting command for xml-Content: This formatter is used to filter data out of a valid(!) xml string. Multiple hits are possible and are separated by “|” in the response so that further list formatters can be deployed. Syntax: %fxml{NodeName}[={NodeValue}][~{AttributeName}] [={AttributeValue}] Examples: {%fxmlartist} gives back all content of the xml Node with the name “artist” . {%fxmlartist=Depeche Mode} possible but ineffective because no match is defined. {%fxmlartist=Depeche Mode~id} gives back the value of the attribute "id", if the content is the xml Node with the name "artist" "Depeche Mode". {%fxmlartist~id=4711} returns with all contents of xml Nodes with the name "artist", if the value of the "id" attribute is "4711" . {%fxmlartist~id} like {%fxmlartist}: content of the nodes has priority when two criteria are missing. formats response values (only possible with standard commands so far; not for Commandserver Replays).

Examples of the use of the format options: The normal Callup delivers play mode, e.g., 521 seconds back.

Callup: Response: GETCTIME=08:41|OK

3.4. Formatting Options, Parsing Options, Status Port 59 nomos Documentation, Release 1.1.73

Minutes and seconds are initially computed. Then the minutes are displayed as two digits with left-hand zeroes, a ":" as separator is incorporated and ﬁnally the seconds added in two digits.

Callup: Response: GETCTIME=00:08:41|OK

If one merely wants to constrain left-hand zeroes for a value, one enters only the "seconds" formatter:

Callup: Response: GETCTIME=0000521|OK

When arguments are to be formatted (functions in principle exactly as above), it should be noted that the format string is appended behind the argument:

Callup: Response:

Examples for the list output: gives back as a list 5 names of folders from Index 17. delivers the ﬁle names of Index 12 through Index 8, starting with Index 12 delivers as follows the names of all albums from the iTunes databank and places the number of the elements (hits) on this top in the response : GETALLALBUMS{%lc}= (4) |All The Lost Souls|Café del Mar: The Ibiza Clubmixes (2008)|Embrya|Lounge Top 55 Deluxe|Pacha - The World’s Most Famous Club Sound 2008|OK

delivers the title names for the requested ID’s and returns these names sorted. gives a list of all albums, which begin with „c“. (not case sensitive) delivers a list of all albums and ﬁlters out any duplications. Examples for universal format strings:

3.4. Formatting Options, Parsing Options, Status Port 60 nomos Documentation, Release 1.1.73

delivers, e.g., „Cafe Del Mar“ returns the string starting from Position 5 with the length 3, namely „Del“ gives back the string „Del Mar * Cafe“. Outputs the string from Position 5 in the Length 14. Since the desired length of the string exceeds the rest of the whole string, ” * ” is included and the string is read again from the beginning until the 14 places are reached. When the {Index} -value is larger than the length of the string, it is automatically recomputed downward. A "boiling down" of high {Index} -values is therefore not possible. converts the command into , thus replacing all „BLANKS“ HTML-compatible in %20. becomes

raises the value of the system variable [TEMP] by 1.5. generates the answer: If one now, taking the previous examples into account, proceeds to:

GETIDTITLE{%tmRemotePlaylist}=\*|OK match, one can make a clear assignment without running the risk that another query for generation of a new list is engaged. Typically even possible match conditions can be formatted into Event deﬁnitions alone in this way on the TAG names, namely, e.g., to {%tmRemotePlaylist}=\*|OK. The initiator (GETIDTITLE or GETIDALBUM) of the list remains entirely uninvolved herel. Thus can outputs (m..Remote), for example, be used several times. („%t“ has therefore no true function, but offers only a mark of differentiation through the separation sign „|“).

3.4. Formatting Options, Parsing Options, Status Port 61 nomos Documentation, Release 1.1.73

3.4.2 Conversion Options

Employment of code-converter options, which are able to recompute, transform or convert an argument. This is necessary, for example, in order to recompute values into HEX or to calculate other values, as the following examples should illustrate. The option, expressed within „{}“ is appended to the argument that is supposed to be recomputed. The following conversion options are currently available: conversions: %dec transforms a HEX value into the equivalent decimal number %ascii transforms a HEX sequence into ASCII characters %hex{Digits} transforms a decimal-system number or an ASCII sequence into a HEX number with {Digits} (for decimal numbers only). {Digits} is optional. Maximum of 8 digits possible %raw ensures that the normally implicit conversion of the matches into a decimal-system number is prevented for HEX Command- and Event Servers. The combination of {%raw,%ascii} ensures, for example, that a Hex sequence is expressed as an ASCII String. %pre{Text} inserts {Text} in front of the String. %suf{Text} appends {Text} after a String Calculation Operations: %-{Value} subtracts {Value} from Argument %+{Value} adds {Value} from Argument %/{Value} divides {Value} of Argument; where {Value} = „0“, no calculation results txt-command:%*{Value} multiplies {Value} of Argument The options can also be applied and consolidated repeatedly. To be noted here is that the computation of the various values is always based on the result from the previous option. to illustrate: if a hexadezimal value 0A were converted into a decimal value (10): The value would now be raised by 30 to (40) and then be divided by 2. The result, 20 , would then be sent on. Application of various conversion options: Examples: becomes converts the hexadecimal value „2F“ into the decimal number 47. becomes changes the hexadecimal values into equivalent ASCII characters

3.4. Formatting Options, Parsing Options, Status Port 62 nomos Documentation, Release 1.1.73

becomes changes the decimal number into a hexadecimal number becomes changes the decimal number into a hexadecimal number and forces a response with 4 digits. becomes nomos recognizes that the argument is composed of more than just digits and therefore changes everything into ASCII character symbols. In this mode, the complete string is always converted. {Digits} has no bearing on this. becomes Adds the value 10 to the argument becomes Divides the argument by the value 2

Complex: becomes 0A is converted into the decimal-system number 10 . This value is raised by 30. The result is multiplied by 2. This new result is divided by 4 and reduced then by 3.

3.4. Formatting Options, Parsing Options, Status Port 63 nomos Documentation, Release 1.1.73

3.4.3 Parsing Options (Match Conditions)

The nomos system generates various outputs at the different ports. These outputs can be generated automatically or, for example, with MAPPINGS entries in the CommandServer definitions. Matches are case-insensitive. In order to extract specific information from the textual contents, the following Match Conditions/Parser Options are now used: Explanation of the Characters: \^ (\#) matches a character. For each „^“ , a character is anticipated. „#“ is also valid here, but should be avoided because it is employed also as argument. \* matches a chain of characters \? i generates a character \% ignores as many characters as desired \!{Digits}! skips {Digits}. {Digits} may have a maximum of 4 digits and has to be given in decimal system. Please note: With a HEX match, a Byte corresponds to two digits. Matches are case-insensitive. Please find further explanation and examples for employment in the Chapters: CommandServer and EventServer .

3.4. Formatting Options, Parsing Options, Status Port 64 nomos Documentation, Release 1.1.73

3.4.4 Arguments (transferral)

Character chains or values that were analyzed after the previously mentioned match conditions are „buffered“ and can be transferred with the following arguments Explanation of the characters: \# transfers the content of the match sequence (and the „Buffer“) \$ transfers the content of the match sequence (and the „Buffer“ as list) comple- menting \$: \& Index of lists only in combination with „\$“ \§ transfers the JOIN number (only mremote.csv) Further explanations and examples for employment are found in the Chapters: CommandServer and EventServer .

3.4. Formatting Options, Parsing Options, Status Port 65 nomos Documentation, Release 1.1.73

3.4.5 Automatically generated output (Statusport)

The nomos system generates automatic Broadcast output on pre-installed Port 1038. Generated in this way are automatic status and such information on individual applications as, e.g., the current sound volume or iTunes title currently playing. These outputs can, for example, be analyzed with the Eventserver or within the mremote interface and further actions can alo be triggered. The following data are automatically generated through the Broadcast Port: ITUNES:

GETPLAYERSTATE= PLAYING/STOPPED/PAUSED GETPLAYLIST= Name of the current playlist GETTITLE= Name of the title GETSTREAMTITLE= Name of the streaming title (IP radio station) GETARTIST= Name of the performer GETALBUM= Name of the album GETID= Title ID GETINDEX= Index of the title in the current playlist GETRATING= Rating categories (0-5) [REMOTE]:

GETINFO= PLAYING/STOPPED/PAUSED SHUFFLE= Shufﬂe status REPEAT= Repeat status ITLE= Name of the performer ALBUM= Name of the album GENRE= Title ID DVD:

GETDVDSTATE= PLAYING“/“STOPPED“/“PAUSED GETTITLE= Name of the title GETCHAPTER= Number of the current chapter

3.4. Formatting Options, Parsing Options, Status Port 66 nomos Documentation, Release 1.1.73

GETVOL= Sound volume TV:

GETCH= Current channel number GETCHNAME= Current name of the station GETPROGINFO= with the following content: Starting time of current broadcast program Ending time of current program Brief information on current program Long text of current program Starting time of next program Ending time of next program Brief information on next program Long text of next program GETVOL= Application’s sound volume GETTUNER= Name of the tuner that is currently in the foreground (only with several tuners present in the system) SYS:

GETVOL= with the following content: Audio output EXT/INT Sound volume VOL={0-100} Mute MUTE={ON/OFF} GETSS= State of the viewing screen-saver {ON/OFF} Follow-Me Status: „FMINFO=...|OK“ Transfer of callup parameter for the playing of a DVD on a remote system The following classes also generate Broadcast Status outputs. Their assigned explanations are found in the respective chapters. xPL (when valid (= defined in the .csv ) xpl-message received) HS (always, if something is being received) KNX (always, if the address in the .esf is defined) BAOS (if the datapoint had been defined in the .csv ) ZWAVE (Status changes of registered devices) HUE (Status changes of registered devices) SONOS (title information and status reports)

3.4. Formatting Options, Parsing Options, Status Port 67 nomos Documentation, Release 1.1.73

{CommandServer} (as deﬁned under MAPPINGS )

3.4. Formatting Options, Parsing Options, Status Port 68 nomos Documentation, Release 1.1.73

3.5 Command Classes

The nomos system has the following internal command classes:

Class Description os x linux BROWSER Control of the integrated Internet browser (Safari) x DVD Control of the application for the DVD replay x ITUNES Control of the multimedia application iTunes x SLIDE Control of the integrated picture slideshow x SCRIPT Command class for management of local scripts x x SCRIPTLOAD Command class for loading scripts to the nomos system x x SYS System commands independent of applications x x(teil) TV Control of the TV application (EyeTV) x VLC Control of the VideoLAN Clients x UDP Dispatch of „free“ UDP datagrams x x TCP Dispatch of „free“ TCP packets x x Commands class for the display of free window contents WINDOW x (Text/Graphic/Browser) KNX KNX/IP - Support x x BAOS BAOS Object Server - Support x x HS GIRA Homeserver KO-Gateway Support x x TIMER Timer Support x x QUICKTIME Control of the multimedia application Quicktime x [dynamic] Control of Remote and Sonos classes x x

The limitations of the LINUX set of commands affect only the local control of the software applications, since they are only available on the Apple OS X system. The commands can be used, nevertheless, in order to carry out these functions on remote systems, as long as the nomos software is available there. For example, an iTunes or Safari Browser on a remote Apple Computer can therefore be accessed through a nomos Box. Refer here also to the Relay Funktion.

3.5. Command Classes 69 nomos Documentation, Release 1.1.73

3.6 Standard Command Set

The Standard Command Set is ﬁrmly integrated into the nomos system. With few exceptions, the command set is compatible with all platforms. The command set can be expanded nearly at will through the CommandServer interface.

3.6.1 BROWSER

Command set for controlling the Safari Web Browser application (only OS X).

Command Argument Description ON - starts the browser OFF - ends the browser CLOSEAWIN - closes all browser windows CLOSEFWIN - closes the last browser window MINFWIN= {0} or {1} minimizes (1) or maximizes (0) the last window MINAWIN= {0} or {1} like MINFWIN, but for all windows URL= {URL} opens the given URL in a new window ZOOM= {0} or {1} enlarges (1) or reduces (0) the current window WFORMAT= {xmin,ymin,xmax, ymax} scales the current window to the given range SHOW - makes application visible HIDE - occults the application FRONT - brings the application to the front FULL or {XMAX, WINSIZE= YMAX} or {XMIN, changes the window size (origin lower left) YMIN,XMAX,YMAX} Explanation: FULL: strretches the window to the viewing screen resolution (as far as the application permits) XMAX,YMAX: centers the window with the expansion Xmax,Ymax on the screen XMIN,YMIN,XMAX,YMAX: positions the window with the expansion Xmax,Ymax and the origin Xmin,Ymin on the screen

3.6. Standard Command Set 70 nomos Documentation, Release 1.1.73

3.6.2 DVD

Command set for controlling the DVD-Player application (only OS X).

Command Argument Description ON - starts the DVD Player application OFF - ends the DVD Player application PLAY - plays the inserted DVD STOP - stops the DVD PAUSE - pauses the playing of the DVD FF - fast forward REW - fast rewind EJECT - ejects the DVD form the drive URL= {URL} opens the given URL FSON - activates full-screen mode FSOFF - deactivates full-screen mode MUTEON - turns off the tone MUTEOFF - turns on the tone SHOW - makes application visible HIDE - conceals the application FRONT - repositions the application to the front UPKEY - simulates the key stroke (Menu-Navigation) DNKEY - simulates the key stroke (Menu-Navigation) LEKEY - simulates the key stroke (Menu-Navigation) RIKEY - simulates the key stroke (Menu-Navigation) ENKEY - simulates the key stroke (Menu-Navigation) GETPTIME - reports the current playing time in seconds SETPTIME= {1...x} jumps to the given play time GETCTIME - delivers the entire play time in seconds GETCHAPTER - delivers the current chapter SETCHAPTER= {1...x} jumps to the given chapter GETALLCHAPTERS - delivers the total number of all chapters GETMEDIASTATE - delivers the media state of the DVD GETMENUSTATE - delivers the DVD menu state GETDVDSTATE - delivers the state of tghe DVD GETCONVIS - delivers the state of the controlling window SETCONVIS= {0} or {1} activates/deactivates the control window SETCONPOS= {1...x},{1...y} sets the position of the control window GETINFVIS - delivers the state of the information window SETINFVIS= {0} or {1} activates/deactivates the information window SETINFPOS= {1...x},{1...y} sets the position of the information window reads out the current title number of the inserted GETTITLE DVD SETTITLE= {1...x} jumps to the given title number GETDVDTITLE delivers the current DVD title SETVOL= {0...100} changes the sound volume of the DVD player

3.6. Standard Command Set 71 nomos Documentation, Release 1.1.73

Command Argument Description delivers the volume of the DVD application in GETVOL the range 0...100 FULL or {XMAX, FULL: stretches the window to the screen reso- WINSIZE= YMAX} or {XMIN, lution (as far as the application allows this) YMIN,XMAX,YMAX} XMAX,YMAX: centers the window with the expansion Xmax,Ymax to the screen XMIN,YMIN,XMAX,YMAX: positions the window with the expansion Xmax,Ymax and the origin Xmin,Ymin on the screen

3.6. Standard Command Set 72 nomos Documentation, Release 1.1.73

3.6.3 ITUNES

Command set for controlling the iTunes application (only OS X).

Command Argument Description ADD# {Path} adds a ﬁle to the current playlist ADDIDTOPLAYLIST# {ID},{NAME} adds Title {ID} to the Playlist {NAME} CREATEPLAYLIST# {NAME} creates a new Playlist {NAME} {PL-Name} when no name is creates Playlist {PL-Name} with the content CREATEPLAYLIST FROM- given, list is named automati- of the results of the last search. {PL-Name} is LASTSEARCH# cally optional. DELETEPLAYLIST# {NAME} deletes Playlist {NAME} DISABLECF ends the iTunes Cover Flow starts the iTunes Cover Flow in the full-screen ENABLECF mode FF fast forward FRONT repositions the application to the front GETALBUM delivers the album of the current title comes back with a list of all albums (maximum GETALLALBUMS 250) comes back with a list of all performers (max. GETALLARTISTS 250) delivers all IDs in {Playlist} (maximum GETALLIDSOF PLAYLIST# {Playlist} 250) GETALLPLAYLISTS delivers a list of all available playlists GETALLTITLES comes back with a list of all titles (max. 250) GETARTIST identiﬁes the performer for the current title GETCTIME gives the entire playing time in seconds GETID delivers the {ID} of the current title GETIDALBUM# {ID} delivers the album to the given {ID} GETIDARTIST# {ID} cites the interpreters for the given {ID} delivers the users’ assessment of the {ID} GETIDRATING# {ID} tracks, in a range of (0-5) matching the number of stars GETIDTITLE# {ID} delivers the title to the given {ID} delivers the index of the current title in the cur- GETINDEX rent playlist GETMUTE gives the Mute state GETPLAYERSTATE gives the state of the player GETPLAYLIST delivers the current playlist tells the number of playlists on hand (maximum GETPLAYLISTCOUNT 250) GETPTIME gives the current playing time in seconds delivers the users’ assessment of the current GETRATING tracks, rating range (0-5) matching number of stars gives back the current Repeat mode of the GETREPEAT playlist GETSHUFFLE gives back the current play mode of the playlists

3.6. Standard Command Set 73 nomos Documentation, Release 1.1.73

Command Argument Description GETSTREAMTITLE delivers the title of the current stream GETTITLE gives the current title GETVISSTATE delivers the state of visualization gives the sound volume of the current applica- GETVOL tion HIDE occults the application HIDEPLAYER occults the main window of iTunes MUTEOFF turns off the tone MUTEON turns on the tone NEXT jumps to the next title OFF ends the iTunes application ON starts the iTunes application PAUSE temporarily halts the current title PLAY plays the current title PLAYF# {Path} plays the ﬁle given in {Path} PLAYID# {ID} plays the Title {ID} plays the Playlist {Name}. When {Index} is PLAYPLAYLIST# {Name},{Index} also given, the replay in the playlist starts with this title. See also GETINDEX. PREV jumps to the previous title RESUME continues with replay REW fast rewind SEARCHALBUM# {Album} delivers all IDs, which belong to {Album} delivers a list of interpreters that appear in the SEARCHARTIST# {Searchstring} search string (Limit: 50) delivers a Track-ID List of titles that occur in SEARCHTITLE# {Searchstring} the {Searchstring} (Limit: 50) sets the rating of the iTunesTtitel {ID}, (0-5) SETIDRATING# {ID},{0...5} matched by number of stars SETPTIME# {1...x} jumps to a given play time sets the rating of the current iTunes titel (0-5), SETRATING# {0...5} matched by the number of stars SETREPEAT# {ONE/ALL/OFF} sets Repeat mode of the current playlist switches on or off the Mode Shufﬂe of the cur- SETSHUFFLE# {ON/OFF} rent playlist SETVISSTATE# „0“ or „1“ activates/deactivates visualization sets the system sound volume (iTunes) at 0- SETVOL# {0...100} 100% SHOW makes application visible SHOWPLAYER displays iTunes main window STOP stops the current title URL# {URL} opens the given URL (Streaming) WFORMAT# xmin,ymin,xmax,ymax scales the current window to the given range FULL o. {XMAX,YMAX} FULL or XMAX,YMAX oder WINSIZE# o. {XMIN,YMIN,XMAX, XMIN,YMIN,XMAX,YMAX YMAX}

3.6. Standard Command Set 74 nomos Documentation, Release 1.1.73

3.6.4 SLIDE

Command set for controlling the Slide Show of the iPhoto application (only OS X).

Command Argument Description ON - starts the iPhoto application OFF - ends the iPhoto application START - starts the slide show STOP - ends the slide show PAUSE - temporarily halts the slide show RESUME - resumes showing of slides PREV - jumps back to previous picture NEXT - skips ahead to next picture IMPORT= {Path} imports the pictures in the given path SHOW - makes application visible HIDE - conceals the application FRONT - brings the application forward GETALBUMLIST - gives a list of all albums SELALBUM= {Name.sufﬁx} selects the album {Name.suffix} GETALBUM - delivers the name of the current album

3.6. Standard Command Set 75 nomos Documentation, Release 1.1.73

3.6.5 SCRIPT

Command set for processing scripts

Command Argument Description RUN= {Name.suffix} executes .myh -Script {Name.suffix} transfers one or more variable values to the ARG= {Value} script. (fills sequentially the above place-holder ARG) RUNAS= {Name.suffix} executes Apple Script {Name.suffix} RUNSS= {Name.suffix} executes Shell Script {Name.suffix} DELETE= {Name.suffix} deletes Script {Name.suffix} {Name.suffix} renames .myh Script {Name.suffix} as RENAME= ={Name_new.suffix} {Name_new.suffix} LIST - lists all .myh - scripts in the script folder LISTAS - lists all Apple scripts in the script folder LISTSS - lists all Shell scripts in the script folder SHOW= {Name.suffix} shows the content of Script {Name}

3.6. Standard Command Set 76 nomos Documentation, Release 1.1.73

3.6.6 SCRIPTLOAD

Expanded command set for processing Scripts. This command set used as a rule with software for writers or editors.

Command Argument Description Creating-new-Script {Name.myh}. A is docked; all subsequent classes and arguments NAME= {Name.sufﬁx} deﬁne the content of the .myh Script until the Class-Terminator is read

3.6. Standard Command Set 77 nomos Documentation, Release 1.1.73

3.6.7 SYS

OSX Command Argument description only SETVOL= {0...100} x sets the system’s sound volume at 0-100% VOLUP= {0...100} x raises system volume by 0-100% VOLDN= {0...100} x lowers system volume by 0-100% MUTEON - x turns off system tone MUTEOFF - x turns on the system tone GETVOL - x delivers system’s sound volume GETSTATE - x delivers information on the application’s status UPKEY - x simulates the key stroke „Cursor up“ DNKEY - x simulates key stroke „Cursor down“ LEKEY - x simulates key stroke „Cursor left“ RIKEY - x simulates key stroke „Cursor right“ ENKEY - x simulates key stroke „Enter“ SPCKEY - x simulates key stroke „Space key“ TABKEY - x simulates key stroke „Tabulator“ PUSHUPKEY x simulates “hold” key depressed on „Cursor up“ PUSHDNKEY x simulates “hold” key depressed on „Cursor down“ PUSHLEKEY x simulates “hold”key depressed on „Cursor left“ PUSHRIKEY x simulates “hold” key depressed on „Cursor right“ SETMPOS= {0...x},{0...y} x sets mouse pointer at x,y {x,y} or HERE - simulates a mouse click on the position {0...x},{0...y} MCLICK= x x,y, without moving the mouse pointer. HERE clicks on or HERE the current position of the mouse pointer GETMPOS delivers the current coordinates of the mouse pointer activates the FrontRow Application (starting with OSX ENABLEFR - x 10.7 not longer available) deactivates the FrontRow Application (starting with DISABLEFR - x OSX 10.7 no longer available) ENABLESS - x activates the screen saver DISABLESS - x deactivates the screen saver ENABLEDB - x activates the dashboard DISABLEDB - x deactivates the dashboard SHOWDOCK - x shows the dock HIDEDOCK - x hides the dock HIDEALL - x puts all the applications in the background (Hide) HIDESTOPFRONT - x hides, stops and mutes the uppermost application OPEN= {Name.suffix} attempts to open the file {Name.suffix} SHUTDOWN - takes the system down RESTART - starts the system anew EJECT - x ejects the CD/DVD form the drive SLEEP - x suspends activity of the system HELLO - delivers information about nomos

3.6. Standard Command Set 78 nomos Documentation, Release 1.1.73

OSX Command Argument description only delivers information on the currently installed license. Format of the answer: GETLICENSEINFO - {Validity}|{Commandserver}|{Event- Support}|{xPL-Support}|{BAOS-Support}| {Extended-Buttons-Support} delivers information on also present nomos and nomos GETSYSTEMLIST oem systems FADE= {1} or {0} x fades the screen image in or out. fades out the screen image and show the Text {text} MESSAGE= {„text“} x at the center of the screen. A „|“ in the text string causes the lines to advance. Absent from later versions. fades out the text shown with MESSAGE and displays MESSAGEOFF= x the desktop. Absent in later versions SAY= {Text} x transfers a text to the speech output RESTARTSERVICE Starts and resets the Daemon anew. Simulates key stroke [CMD]+{Keycode}. Important: The Apple keyboard code is anticipated, not the ASCII CMDKEY=# {Keycode} x Code! A corresponding table can be found in the attachment on documentation Simulates the key stroke [ALT]+[CMD]+{Keycode}. Important: The ALTCMDKEY= {Keycode} x Apple keyboard code is anticipated, not the ASCII Code! A corresponding table can be found in the attachment on documentation Simulates key stroke [CTRL]+[CMD]+{Keycode}. Important: The Apple keyboard code is anticipated, not CTRLCMDKEY# {Keycode} x the ASCII Code! A corresponding table can be found in the attachment on documentation Simulates key stroke SHIFTCMDKEY# {Keycode} x [SHIFT]+[CMD]+{Keycode} Simulates key stroke. Important: The Apple keyboard code is anticipated, not the ASCII Code! A correspond- KEY# {Keycode} x ing table can be found in the attachment on documentation FMINIT - x Initializes the Follow-me status delivers the generated Follow-me string. (assumes a FMREAD - x previous, successful FMINIT.) leaves the Follow-me status. (assumes a successful FMEXIT - x FMINIT has preceded it.) breaks of the Follow-me and commences the return. FMABORT - x (assumes a successful FMINIT has preceded it.) delivers the current Follow-me status (TV,DVD,...) FMINFO - x (also present in Broadcast) internal command for initiating the read-in of the Ad- GETSRVLIST - dOn commands. After it is triggered, the menu is expanded with possibly available AddOn’s internal command for initiating the read-in of the xPL GETXPLLIST - commands. When triggered, the menu is expanded with possibly available AddOn’s GETFILENUMIN {Path} delivers the number of ﬁles present in {Path} FOLDER=

3.6. Standard Command Set 79 nomos Documentation, Release 1.1.73

OSX Command Argument description only GETFOLDERNUMIN {Path} delivers the number of indices present in {Path} FOLDER= GETFILESIN- {Path,Index=x, delivers a list of the files present in {Path}; index and FOLDER= Length=y} length are optional GETFOLDERSIN {Path,Index=x, delivers a list of the indices available in {Path} ; index FOLDER= Length=y} and length are optional {ButtonBar- OPENBUTTONS= x opens the button bar Name} {ButtonBar- CLOSEBUTTONS= x closes the button bar Name} SETBUTTON- {ButtonBar- sets the condition of a button when pressed (if a toggle x PUSHED= Name} button) SETBUTTON RE- {ButtonBar- sets the condition of a button when not being pressed (if x LEASED= Name} toggle button) CLOSECURRENT x closes the button bar that was currently open BUTTONS {Button- SETBUTTONLA- BarName}, x changes the label of the button briefly BEL= Index{1-10}, {LabelText} {Button- SETALTBUTTON LA- BarName}, x changes briefly the second label of a SWITCH button BEL= Index{1-10}, {LabelText} SHOWKEYBOARD x fades in the (keyboard) input assistance HIDEKEYBOARD x fades out the (keyboard) input help {Variable- GETVAR= reads the value of a system variable name} {Variable- changes the value of a system variable or imposes a SETVAR= name}, value {Value} {Variable- DELVAR= deletes a system variable name} Query and response for the values of all the available GETALLVARS variables blocks or enables the writing of variables to the data LOCKVARS= {ON/OFF} storage medium continues the current sequence until the Sysvar {Variablename} has accepted the Value {Value} . If {Timeout} (in ms) is also given, then it waits out {Variable- a {Timeout} - milliseconds. When this time runs out WAITVAR= name}, and the {Variable} never has {Value} , then the {Value}{,{Timeout}} rest of the sequence is NOT worked through but is disregarded. An "IF -> THEN" temporal dependency can be constructed with this. GETSERIAL- lists all serial ports on hand in the system PORTLIST lists all available Airports with names (“Computer” is GETSPEAKERLIST x the local tone of the Apple computer) - Airfoil GETSPEAKER- gives the current application or the active entrance of x SOURCE the sound that is just being streamed - Airfoil

3.6. Standard Command Set 80 nomos Documentation, Release 1.1.73

OSX Command Argument description only SETSPEAKER selects the application that is supposed to be streamed - {Appname} x SOURCE= Airfoil SETSPEAKER- selects the audio input through which to be streamed - {Input} x SOURCE DEVICE= Airfoil GETAUDIODEVICE x lists all available audio entrances - Airfoil LIST {Airport- GETSPEAKERVOL= x queries the volume of the selected Airport -Airfoil Name} {Airport- sets the absolute sound volume of the selected Airport; SETSPEAKERVOL= Name}, x if the name is omitted, the volume of all Airports (in- {0...100} cluding “Computer”) is set - Airfoil {Airport- raises the volume by a given value; name is optional SPEAKERVOLUP= Name}, x here - Airfoil {0...100} {Airport- lowers the volume; otherwise is like SPEAKERVOLUP SPEAKERVOLDN= Name}, x -Airfoil {0...100} {Airport- ENABLESPEAKER= x turns on the selected Airport - Airfoil Name} {Airport- DISABLESPEAKER= x turns off the selected Airport - Airfoil Name} ENABLEALL x turns on all Airports - Airfoil SPEAKERS DISABLEALL x turns off all Airports - Airfoil SPEAKERS GETSPEAKER- {Airport- delivers the state of the selected Airport: ENABLED / x STATE= Name} DISABLED / NOT_AVAILABLE - Airfoil {Num- SETDIGITALJOIN= mRemote Support - sets digital Join (0/1) ber},{Value} {Num- SETANALOGJOIN= mRemote Support - sets analog Join (0-65535) ber},{Value} {Num- SETSERIALJOIN= mRemote Support - sets serial Join (String) ber},{Value} sends a „Magic Packet“ for the given MAC address. {MAC- WAKEONLAN= The way in which the Mac address is written is irrel- Address} evant, as long as exactly 6 Octets are entered. GETAUDIOOUTPUT x lists all available audio output devices with names LIST GETAUDIOOUTPUT x delivers the current output device SETAUDIOOUTPUT= {Name} x switches to output device {Name}

{x,y,bpp},{x,x}, changes the viewing screen resolution, is supported SETDISPLAYMODE= x “0” or “NOR- {x,y,bpp}, {x,x}, "0" or "NORMAL" MAL” delivers the current system time in the KNX EIS3 for- GETTIME mat GETDATE delivers current system date in the KNX EIS3 format initializes the Counter {Name}.{Startvalue} and SETCOUNTER= {Name}{,Startvalue} {Increment} are optional. Default is 0 for {,Increment} {Startvalue} and 1 for {Increment}

3.6. Standard Command Set 81 nomos Documentation, Release 1.1.73

OSX Command Argument description only {Name} {,In- changes the size of the step of an existing Counter SETCOUNTERSTEP= crement} {Name}, 0 for {Increment} stops the counter delivers the current value of the Counter {Name}, with- GETCOUNTER= {Name} out changing it delivers the current value of all counters, without chang- GETALLCOUNTERS ing them GETREMOTEDE- delivers a list of all devices defined in the VICE LIST remote.csv GETVPNIP delivers the VPN IP, in case there is a VPN connection Starts {ON} /ends {OFF} the Pairing Mode for iTunes REMOTEPAIRING= {ON/OFF} and AppleTV in the remote class converts coloration values from the HSV color space {H(0-360),S(0- CONVERTHSV- into RGB. Value: H= color angle (0-360°) - S= satura- 255), V(0- TORGB# tion (0-255) - V= brightness (0-255), return = R,G,B in 255)} the value range 0-255 {R(0-255)}, CONVERTRG- converts RGB color values into the HSV color space. {G(0-255)}, BTOHSV# Values: R=(0-255) - G=(0-255) - B=(0-255) {B(0-255)} GETSONOSDE- delivers the class names of all device defined in the VICELIST sonos.csv GETXBMCDE- delivers the class names of all devices defined in the VICELIST xbmc.csv

Notice on SETDISPLAYMODE command: If the input cannot be converted (resolution and/or color depth), the next possible mode setting automatically kicks in (see Log). It is not possible to install modes that are not supported by the viewing screen. When mmh is ended, the screen is reset to its original mode.

3.6. Standard Command Set 82 nomos Documentation, Release 1.1.73

3.6.8 TV (Elgato eyeTV)

Command set for control of the eyeTV application (only OS X).

Command Argument Description SETVOL= {0...100} sets the system sound volume (TV) to 0-100% ON - starts the TV application OFF - ends the TV application PLAY - starts playback PAUSE - temporarily halts playback STOP - stops playback FF - fast forward REW - fast rewind SLOWF - slow motion forward SLOWR - slow motion backwards SKIPF - jumps forward SKIPR - jumps backward RECSTART - starts recording RECSTOP - ends recording CHUP - moves channel higher CHDN - moves the channel lower FSON - activates full-screen mode FSOFF - deactivates full-screen mode ZOOM= {1} or {0} enlarges (1) or shrinks (0) the current window WFORMAT= {xmin,ymin,xmax, ymax} scales the current window to the given range SHOW - makes the application visible HIDE - conceals the application FRONT - brings the application forward HIDECON - conceals the console window SHOWCON - shows the console window CH= {1...x} selects the channel GETCH - gives the current channel’s number GETCHNAME= {1...x} gives the channel name for the channel number MUTEON - switches the application’s tone off MUTEOFF - switches the application’s tone on ENABLEEGP - switches the EPG display on DISABLEEPG - switches the EPG display off delivers information on the current and the subsequent broadcast in the format: {Start}|{Stop}|{title of GETPROGINFO the current broadcast}|{brief description}|{Start}|{Stop}|{title of the next broadcast}|{brief description} FULL/{XMAX,YMAX}/ Changes the size of the window (origin lower WINSIZE= {XMIN,YMIN,XMAX, left) YMAX} Explanation:

3.6. Standard Command Set 83 nomos Documentation, Release 1.1.73

Command Argument Description FULL: stretches the window to the screen resolution (as far as the application allows). XMAX,YMAX: centers the window with the spread XMAX, YMAX on the screen. XMIN,YMIN,XMAX,YMAX: positions the window with the spread XMAX,YMAX and the origin XMIN,YMIN on the screen. ENABLEMENU displays the eyeTV-OSD Menu DISABLEMENU causes eyeTV-OSD Menu display to vanish ENABLEFSEPG brings up the full-screen EPG display DISABLEFSEPG occults the full-screen EPG display

3.6. Standard Command Set 84 nomos Documentation, Release 1.1.73

3.6.9 VLC

Command set for controlling the VLC application (OS X only).

Command Argument Description ON - activates the VideoLAN client OFF - deactivates the VideoLAN client URL= {URL} opens the File/Stream {URL} TPLAY - toggles the Play state STOP - stops the replay PREV - jumps back to the previous title NEXT - jumps ahead to the next title TFS - toggles the full-screen mode TMUTE - toggles the mute state VOLUP - raises the sound volume VOLDN - reduces the sound volume ZOOM= {1} or {0} enlarges (1) or shrinks (0) the current window WFORMAT= {xmin,ymin,xmax, ymax} scales the current window to the given range SHOW - makes the application visible HIDE - conceals the application FRONT - brings the application forward FULL/{XMAX,YMAX}/ WINSIZE= {XMIN,YMIN,XMAX, changes the window size (origin lower left) YMAX} Explanation: FULL: stretches the window to the screen resolution (as far as the application permits). XMAX,YMAX: centers on the viewing screen the window with the spread dimensions XMAX, YMAX. XMIN,YMIN,XMAX,YMAX: positions on the screen the window with the spread dimensions XMAX,YMAX and the point of origin XMIN,YMIN.

3.6. Standard Command Set 85 nomos Documentation, Release 1.1.73

3.6.10 UDP/TCP

The UDP/TCP command class offers the possibility to send as many protocols as desired to a device directly. When employing this option, no additional CommandServer is needed. The Class conforms to the Class .

Command Argument Description IP= {IP Address}x IP Address of the receiver in point notation PORT= {PORT} Port Address of the receiver establishes the mode of transmission (HEX MODE= {„HEX“,“ASCII“, “BIN“} only at the moment) optional, sets down the Timeout in seconds that TIME= {t} in seconds 0 - 3600 must be allowed to elapse when awaiting an answer data content of the UDP packet in the MODE DATA= {Data} format

Examples:

Sends a UDP data packet with the content "ABC" to the IP 192.168.50.1 at Port 4000 and waits 5 seconds on an answer or answers. Data received during the Timeout period is immediately sent onward until the Timeout expires. If no Timeout has been given (or TIME=0), the Packet is merely sent along and no answer is awaited. The maximum possible Timeout value is ﬁxed at 3600s.

Sends the system command Mute to the “remote” nomos system with the address 192.168.50.125 After the dispatch of a UDP packet, the Daemon immediately returns to the Kommando Mode and processes any further commands that are pending. The use of TCP connections occurs similarly:

Sends a TCP data packet with the content "ABC" to the IP 192.168.50.1 at Port 4000 and waits 5 seconds on an answer or answers. Data received within the timeout period are immediately forwarded until the Timeout expires. If no Timeout period is given (TIME=0), the packet is merely sent along and no answer is anticipated. The maximum possible Timeout value is ﬁxed at 3600s.

Sends the system command Mute to the “remote” nomos system with the address 192.168.50.125

3.6. Standard Command Set 86 nomos Documentation, Release 1.1.73

3.6.11 WINDOW

When using the WINDOWS class (OS X only), the following should be considered: WINDOWS are generated from the SAFARI Browser in the Kiosk Mode (Frameless). Accordingly, all content that can be shown and controlled with the SAFARI Browser and its possible PlugIn’s can also be generated in this class. Also noteworthy is the „Schichtenmodel“ (LAYER). With this feature the WINDOWS are arranged by priority. Thus, one can direct whatever WINDOW is to be displayed to the „highest“ position. The Layer feature permits a choice between two priority groups with different priorities. This is deﬁned from the LEVEL and with the SELECT command. When a LEVEL is not assigned, LEVEL=NORMAL is automatically assumed. The “space” in which the window occurs is chosen with Level. The selection of a pecking order of windows within this “space” can always be made with the help of the SELECT command. A window with SELECT=2 is therefore situated on top of a window with SELECT=1, if both possess the same Level. Accordingly, a window with SELECT=3 and LEVEL=HIGH comes atop(!) a window with SELECT=4 and LEVEL=NORMAL, although the ID of the upper window is lower. The LEVEL command can be employed any time (even for windows that are already displayed).

Command Argument Description X coordinate of the lower left corner of the win- XMIN# {0...} dow (mandatory), default=0 Y coordinate of the lower left corner of the win- YMIN# {0...} dow (mandatory) X coordinate of the upper right corner of the XMAX# {0...} window (mandatory), default=max Y coordinate of the upper right corner of the YMAX# {0...} window (mandatory) NORMAL (default): Window over all normal LEVEL= {LOW,NORMAL,HIGH} windows, below the screen saver. HIGH: over the screen saver LOW: Window under all windows, on the Desktop background When XMIN and YMIN are missing in a window conﬁguration, the window is automatically Ext. use of X/YMIN/MAX displayed as centered. XMIN and XMAX are preallocated with Default values to the Banner representation in screen width SHADOW# „0“ or „1“ draw shadow? Transparency of the window (mandatory) - This command can also be used later on a window al- TRANS# {0.0...1.0} ready in use, e.g., for slowly fading in. default= 0.9 TITLE# {Text} Title of the window opens the URL in the window - no further com- URL# {Text} mands needed

3.6. Standard Command Set 87 nomos Documentation, Release 1.1.73

Command Argument Description displays a local or remote picture. The image can be given either as path (e.g. "/Users/MyH/..." ) or as URL ( IMAGE# {Text(URL/Path)} "http://....." ). The rules for dis- playing the picture apply analogously to the URL command centers TEXT in the window – further commands needed. A pipe character in the text to TEXT# {Text} be displayed generates a line feed to the appropriate position. The currently preset typeface for all text displays is Helvetica Bold Oblique TEXTSIZE# {0.0...1.0} Text size in pixels (mandatory) TEXT_RED# {0.0...1.0} Red portion of text coloring- default: 1.0 TEXT_GREEN# {0.0...1.0} Green portion of text coloration - default: 1.0 TEXT_BLUE# {0.0...1.0} Blue portion of text coloration - default: 1.0 Transparent portion of text coloring - default: TEXT_TRANS# {0.0...1.0} 1.0 BACKGROUND_RED# {0.0...1.0} Red portion of the text background - default: 0 BACKGROUND_GREEN# {0.0...1.0} Green portion of text background - default: 0 BACKGROUND_BLUE# {0.0...1.0} Blue portion of the text background - default: 0 Transparent portion of the text background - de- BACKGROUND_TRANS# {0.0...1.0} fault: 1.0 slowly fades the current transparency of the FADETO# {0..1.0} window to the given value Conclusion of the conﬁguration: generates the CREATE window on the viewing screen, if not open. (mandatory) RELEASE Removes the window from the screen MINIMIZE minimizes window in the dock MAXIMIZE reconstitutes window in the dock Window selection (1-10). All following commands apply always to the window previously chosen with SELECT . SELECT is optional SELECT# {1...10} (Default value: 1 ). The higher the value, the higher the priority. A WINDOW with SELECT=2 therefore lies over the WINDOW with SELECT=1 RELEASEALL closes all windows and sets SELECT on 1 RESET deletes all windows and sets all parameters to 0 EFFECTCREATE like CREATE, but with animation EFFECTRELEASE like RELEASE, but with animation repositions a window that was already opened MOVE to new coordinates, which have been set in the interim EFFECTMOVE like MOVE, but with additional animation

3.6. Standard Command Set 88 nomos Documentation, Release 1.1.73

3.6.12 BAOS

Set of commands for the use of the BAOS Class. This class is available only when the appropriate AddOn is engaged. Additionally, the corresponding definition file, ../misc/baos.csv , has to be defined for the AddOn. Explicit information on this application is found in the Chapter: KNX-IP Baos 770

Command Argument Description GETINFO delivers general information on BAOS GETDESCRIPTION= {DatapointNumber} delivers the settings of the selected datapoint GETDESCRIPTIONSTRING= {DatapointNumber} gives the description of the chosen datapoint gives the current value of the datapoint, includ- GETVALUE= {DatapointNumber} ing status-ﬂags in HEX format {DatapointNumber}, sets the value of the selected datapoint in HEX, SETVALUE= {HEX/DEC/ASCII} Decimal or as ASCII {DatapointNumber}, { SENDVALUE= sends the value to the KNX bus HEX/DEC/ASCII} {DatapointNumber}, { SETANDSENDVALUE= combination of SETVALUE and SENDVALUE HEX/DEC/ASCII} {DatapointNumber}, READVALUE= reads the value from the KNX bus {HEX/DEC/ASCII} CLEARTRANSMISSION- {DatapointNumber}, deletes the connection state STATE= {HEX/DEC/ASCII} GETPARAMETERBYTE= {ParameterNr.} gives the Byte of the selected parameter

3.6. Standard Command Set 89 nomos Documentation, Release 1.1.73

3.6.13HS

Set of commands for working with the GIRA Homeserver KO-Gateway. This class is available only if the appropriate AddOn is engaged. The corresponding definition file, ../misc/hs.csv , must also be defined for the AddOn. Explicit information on the application can be found in the Chapter: GIRA Homeserver KO-Gateway Support

Command Argument Description SETVALUE# {address},{value} sets absolute {value} to {address}. SETVALUEREL# {address},{value} sets relative {value} to {address} . STEPUP# {address} raises the value to {address}. STEPDOWN# {address} lowers the value to {address}. LISTUP# {address} raises the value to {address}. LISTDOWN# {address} lowers the value to {address}.

3.6. Standard Command Set 90 nomos Documentation, Release 1.1.73

3.6.14 KNX

Set of commands for the use of the KNXnet/IP Protocol (Tunneling/Routing). This class is available only when the appropriate AddOn is engaged. Additionally, the corresponding definition file ../misc/knx.csv has to be defined for the AddOn. Explicit information for this application is found in the Chapter: KNXnet/IP Protokoll Support

Command Argument Description SETVALUE= {Address},{Value} sets {Value} of {Address} GETVALUE= {Address} reads out a value of an {Address} Scans a list of addresses as deﬁned in the SCAN= {Tablename} knx.csv As the previous, except all registered tables are BACKGROUNDSCAN= {Tablename},{ALL} scanned with {ALL} when the scan runs in the background

For the deployment of the KNX Class, the datapoints that are to be contacted have to be available in the deﬁnition ﬁle ../misc/knx.esf .

3.6. Standard Command Set 91 nomos Documentation, Release 1.1.73

3.6.15 STREAMER

Set of commands for steering the Streamer function for the eyeTV application (OS X only). This class is available only if the appropriate AddOn is engaged. Detailed information on the application can be found in the Chapter: eyeTV - Streaming Support

Command Argument Description starts the Streaming Engine and, if applicable, ON EyeTV (minimized) ends the Streaming Engine, EyeTV keeps run- OFF ning selects the source of Streaming. This command works analogously to the SELECT command in {ChannelNumber} or {Chan- CH# the windows class. All subsequent, channel- nelName} related commands pertain to last channel that was selected with CH delivers a list with all the channels available at GETCHLIST the moment along with their channel numbers. assigns a target to the source previously selected and immediately starts the UDP Stream- ing to the given address. An unmistak- ADDTARGET# {IP:Port} able Streaming ID is returned. Please transmit to the VLC of the client as URL udp://@:{Portnumber}. stops the streaming of the stream via IP:Port {IP:Port} or {Streaming-ID} or REMOVETARGET# or ID. If only the IP is given, all streams di- {IP} rected at this IP are stopped. REMOVEALLTARGETS stops all streams GETTARGETSFORIP# {IP} lists all streams directed to the IP {ChannelNumber} or {Chan- lists all IP addresses to which the channel GETTARGETSFORCH# nelName} is being streamed GETALLTARGETS lists everything that is being streamed

3.6. Standard Command Set 92 nomos Documentation, Release 1.1.73

3.6.16 TIMER

Set of commands for manipulation of the Timer/Calendar functions (Examples)

Command Argument Description {Name},{Timertype}, {Value generates a new timer and writes it into the CREATE# or Date string}, {Timeraction} timer.csv deletes an existing timer (and stops it in any DELETE# {Name} case) removes AUTOSTART from the timer.csv DISABLE# {Name} and stops the timer, in case it was running writes AUTOSTART behind an existing timer in ENABLE# {Name} the timer.csv and starts it, in case that had not yet happened LIST lists all active timers LISTALL lists all deﬁned timers by their names RESET# {Name} sets the Timer {Name} back START# {Name}{Name} startet den Timer {Name} STOP# {Name}{Name} stoppt den Timer {Name} LIST# {Name} listet alle aktiven Timer {Name}

Timer deﬁnitions have to be entered in the File ../misc/timer.csv

3.6. Standard Command Set 93 nomos Documentation, Release 1.1.73

3.6.17 QUICKTIME

Set of commands for controlling the Quicktime application (OS X only)

[QUICKTIME]Command [QUICKTIME]Argument [QUICKTIME]Description CLOSE# {Window title} closes Window {Window title} CLOSEALL closes all windows FRONT brings forward the Quicktime application FSOFF# {Window title} activate the tone output FSON# {Window title} turns on the full-picture display GETALLWINDOWS delivers a list of all window titles present GETCTIME# {Window title} gives the entire playing time in seconds GETFRONTWINDOW gives the title of the ﬁrst window GETPTIME# {Window title} gives the current playing time in seconds GETSPEED# {Window title} reports the current replay speed and direction GETVOL# {Window title} reports the sound volume of the replay HIDE conceals the Quicktime application MUTEOFF# {Window title} activate the tone output MUTEON# {Window title} turns off the tone output OFF ends Quicktime ON starts Quicktime PAUSE# {Window title} interrupts the replay PLAY# {Window title} plays the ﬁle in the window brings forward the Window {Window SETFRONTWINDOW# {Window title} title} (where there are multiple windows) SETPTIME# {Window title},x sets the playing time at {x} seconds SETSPEED# {Window title}, {{-}0.0 ... } controls the replay speed and direction: E.g.

SETSPEED=Matrix.m4v,-2.5 backwards at two-and-one-half times speed, or:

SETSPEED=Matrix.m4v,3.0 three time SETVOL# {Window title}, {0...100} sets the replay sound volume SHOW shows the Quicktime application STOP# {Window title} stops the replay URL# {Path}} opens a ﬁle in the path {Path} {Window title}, WINSIZE# sets the size (and position) of the window {x1,y1},{x2,y2}

Since Quicktime supports several windows at the same time, it is necessary with several of these commands to identify the targeted window by title (corresponds as a rule to the ﬁle name).

3.6. Standard Command Set 94 nomos Documentation, Release 1.1.73

3.6.18 Special Commands

Command Argument Description delays execution of the subsequent commands {t} in seconds (1 for 1sec, 0.5 DELAY= by x seconds. (without class!) Please use al- for 500ms, ...) ways outside a class sequence. The mmh sequence is routed through UDP to a remote nomos system and waits a maximum of 3 seconds for an answer. Example: RELAY= {IP}:{Port} The answer sequence has the syntax: {mmh- Antwortsequenz} ends all the command-set sequences running at BREAK the moment. (without class!)

Special commmand sets should not be used within an opened class. These commands should always be placed after a class is closed or before it is opened. Example:

3.6. Standard Command Set 95 nomos Documentation, Release 1.1.73

3.6.19 CEC

Set of commands for controlling CEC-capable devices. This c lass is available only when the appropriate AddOn has been engaged. No additional conﬁguration ﬁle is necessary for the use of CEC. Please note that these commands are not supported by all devices.

Command Argument Description delivers a list of all devices connected to the GETDEVICELIST CEC bus; from this list one can select a {Device} for further commands. POWER_ON# {Device} turns {Device} on POWER_OFF# {Device} turns {Device} off TV_SOURCE_TUNER switches TV to the local Tuner TV_SOURCE_HDMI1 switches TV to HDMI 1 TV_SOURCE_HDMI2 switches TV to HDMI 2 TV_SOURCE_HDMI3 switches TV to HDMI 3 TV_SOURCE_HDMI4 switches TV to HDMI 4 TV_SOURCE_HDMI5 switches TV to HDMI 5 TV_SOURCE_HDMI6 switches TV to HDMI 6 displays {Text} on the TV (supported only by TV_SHOW_MESSAGE# {Text} a few devices) displays {Text} on the TV and waits for ac- TV_SHOW_POPUP# {Text} knowledgement (supported by only a few devices) AMP_VOLUME_UP raises the sound volume of the AMP AMP_VOLUME_DOWN lowers the sound volume of the AMP AMP_MUTE_ON switches off the tone of the AMP AMP_MUTE_OFF switches on the tone of the AMP manual setting of the address of the CEC SETPHYSICALADDRESS# {Address} adapter Button Commands BUTTON_SELECT# {Device} Function according to device documentation BUTTON_UP# {Device} Function according to device documentation BUTTON_UP# {Device} Function according to device documentation BUTTON_LEFT# {Device} Function according to device documentation BUTTON_RIGHT# {Device} Function according to device documentation BUTTON_RIGHT_UP# {Device} Function according to device documentation BUTTON_RIGHT_DOWN# {Device} Function according to device documentation BUTTON_LEFT_UP# {Device} Function according to device documentation BUTTON_LEFT_DOWN# {Device} Function according to device documentation BUTTON_ROOT_MENU# {Device} Function according to device documentation BUTTON_SETUP_MENU# {Device} Function according to device documentation BUTTON_CONTENTS {Device} Function according to device documentation _MENU# BUTTON_FAVORITE {Device} Function according to device documentation _MENU# BUTTON_EXIT# {Device} Function according to device documentation BUTTON_NUMBER0# {Device} Function according to device documentation

3.6. Standard Command Set 96 nomos Documentation, Release 1.1.73

Command Argument Description BUTTON_NUMBER1# {Device} Function according to device documentation UTTON_NUMBER2# {Device} Function according to device documentation BUTTON_NUMBER3# {Device} Function according to device documentation BUTTON_NUMBER4# {Device} Function according to device documentation BUTTON_NUMBER5# {Device} Function according to device documentation BUTTON_NUMBER6# {Device} Function according to device documentation BUTTON_NUMBER7# {Device} Function according to device documentation BUTTON_NUMBER8# {Device} Function according to device documentation BUTTON_NUMBER9# {Device} Function according to device documentation BUTTON_DOT# {Device} Function according to device documentation BUTTON_ENTER# {Device} Function according to device documentation BUTTON_CLEAR# {Device} Function according to device documentation BUTTON_NEXT _FA- {Device} Function according to device documentation VORITE# BUTTON_CHANNEL_UP# {Device} Function according to device documentation BUTTON_CHANNEL {Device} Function according to device documentation _DOWN# BUTTON_PREVIOUS {Device} Function according to device documentation _CHANNEL# BUTTON_SOUND_SELECT# {Device} Function according to device documentation BUTTON_SOUND_SELECT# {Device} Function according to device documentation BUTTON_DISPLAY _IN- {Device} Function according to device documentation FORMATION# BUTTON_HELP# {Device} Function according to device documentation BUTTON_PAGE_UP# {Device} Function according to device documentation BUTTON_PAGE_DOWN# {Device} Function according to device documentation BUTTON_POWER# {Device} Function according to device documentation BUTTON_VOLUME_UP# {Device} Function according to device documentation BUTTON_VOLUME {Device} Function according to device documentation _DOWN# BUTTON_MUTE# {Device} Function according to device documentation BUTTON_PLAY# {Device} Function according to device documentation BUTTON_STOP# {Device} Function according to device documentation BUTTON_PAUSE# {Device} Function according to device documentation BUTTON_RECORD# {Device} Function according to device documentation BUTTON_REWIND# {Device} Function according to device documentation BUTTON_FAST _FOR- {Device} Function according to device documentation WARD# BUTTON_EJECT# {Device} Function according to device documentation BUTTON_FORWARD# {Device} Function according to device documentation BUTTON_BACKWARD# {Device} Function according to device documentation BUTTON_STOP_RECORD# {Device} Function according to device documentation BUTTON_PAUSE_RECORD# {Device} Function according to device documentation BUTTON_ANGLE# {Device} Function according to device documentation BUTTON_SUB_PICTURE# {Device} Function according to device documentation

3.6. Standard Command Set 97 nomos Documentation, Release 1.1.73

Command Argument Description BUTTON_VIDEO_ON _DE- {Device} Function according to device documentation MAND# BUTTON_ELECTRONIC {Device} Function according to device documentation _PROGRAM_GUIDE# BUTTON_TIMER _PRO- {Device} Function according to device documentation GRAMMING# BUTTON_INITIAL _CON- {Device} Function according to device documentation FIGURATION# BUTTON_PLAY _FUNC- {Device} Function according to device documentation TION# BUTTON_PAUSE {Device} Function according to device documentation _PLAY_FUNCTION# BUTTON_RECORD _FUNC- {Device} Function according to device documentation TION# BUTTON_PAUSE {Device} Function according to device documentation _RECORD_FUNCTION# BUTTON_STOP _FUNC- {Device} Function according to device documentation TION# BUTTON_MUTE _FUNC- {Device} Function according to device documentation TION# BUTTON_RESTORE _VOL- {Device} Function according to device documentation UME_FUNCTION# BUTTON_TUNE _FUNC- {Device} Function according to device documentation TION# BUTTON_SELECT_MEDIA {Device} Function according to device documentation _FUNCTION# BUTTON_SELECT_AV _IN- {Device} Function according to device documentation PUT_FUNCTION# BUTTON_SELECT_AUDIO {Device} Function according to device documentation _INPUT_FUNCTION# BUTTON_POWER_TOGGLE {Device} Function according to device documentation _FUNCTION# BUTTON_POWER_OFF {Device} Function according to device documentation _FUNCTION# BUTTON_POWER_ON {Device} Function according to device documentation _FUNCTION# BUTTON_F1_BLUE# {Device} Function according to device documentation BUTTON_F2_RED# {Device} Function according to device documentation BUTTON_F3_GREEN# {Device} Function according to device documentation BUTTON_F4_YELLOW# {Device} Function according to device documentation BUTTON_F5# {Device} Function according to device documentation BUTTON_DATA# {Device} Function according to device documentation BUTTON_AN_RETURN# {Device} Function according to device documentation BUTTON_AN_CHANNELS {Device} Function according to device documentation _LIST# BUTTON_MAX# {Device} Function according to device documentation

3.6. Standard Command Set 98 nomos Documentation, Release 1.1.73

3.6.20 Z-Wave

Command set for control of registered Z Wave components

Command Argument Description General sets the zwave Controller to the delivery condi- RESET tion and deletes all devices that have been read in starts/ends the Include Mode (inclusion of de- INCLUDE# {ON/OFF} vices) starts/stops the Exclude Modes (removal of de- EXCLUDE# {ON/OFF} vcies) removes a device with “Force” override (e.g., REMOVE# {Node} when the device is defective and can no longer be excluded) DUMPDEVICES reports all read-in devices in the log interviews a device again (takes place automat- INTERVIEW# {Node} ically with Include) takes on another zwave-XML from the Library LOADCONFIG# {Node},{zwaveXML} for the device {Node} stores on the CF card the current condition of SAVE the zwave network updates the Z-Wave network topology, in case UPDATENETWORK Z-Wave nodes were relocalized or the locations were changed. RESETALARM {Node} resets all Alarm reports for the device {Node} Device Configuration starts the zwave stack in the configuration mode (no zwave.csv required), valid CONFMODE# {Port} values for {Port}: /dev/ttyS1, /dev/ttyUSB0, AUTO sets the configuration option {ConfOpt} {Node}, {ConfOpt}, {Conf- CONFIGURE# of the device {Node} to {ConfValue} , Value} {ConfOpt} is a value from 0 to 255 delivers the configuration values of the device GETCONFIGURATION# {Node} {Node} Device Association delivers all Association Groups of the device GETASSOCIATIONS# {Node} {Node} and their content includes the device {AddNode} of the Associ- ADDASSOCIATION# {Node},{Group}, {AddNode} ation Group {Group} in the device {Node} ; {Group} is an Index removes the device {RemoveNode} from the {Node},{Group}, {RemoveN- REMOVEASSOCIATION# Association Group {Group} on the device ode} {Node} Wakeup Handling GETWAKEUPINTERVAL provides for the device {Node} a valid range {Node} RANGE# of values for the Wakeup (in seconds) delivers (in seconds) the currently set Wakeup GETWAKEUPINTERVAL# {Node} value for {Node} SETWAKEUPINTERVAL# {Node} sets the Wakeup value (in seconds) for {Node}

3.6. Standard Command Set 99 nomos Documentation, Release 1.1.73

Command Argument Description Commands switches on or off the switch {Node}, {Value} can be: ON/OFF,0/1,YES/NO. {Node}, [{Instanz/CH}], When [{Instanz/CH}] is used, other pos- SETSWITCH# {Value} sible instances (e.g., multiple channel switch) are accessible. When only {Node} is used, a list of all Instances of the device is reported. GETSWITCH# {Node} provides the status of the switch {Node} sets the dimmer {Node} to the value {Node}, [{Instanz/CH}], {Value} or switches {Node} on or off; SETLEVEL# {Value} {Value} can be: 0-99 , ON/OFF , YES/NO . Otherwise as SETSWITCH# GETLEVEL# {Node} provides the value of {Node} delivers the supported modes of the thermostat GETTHERMOSTATMODES# {Node} {Node} SETTHERMOSTATMODE# {Node},{Mode} switches the Thermostat {Node} to {Mode} GETTHERMOSTATSET delivers the setting points of all modes of the {Node} POINTS# Thermostat {Node} SETTHERMOSTATSET changes the setting point of the thermostat {Node},{Mode},{Value} POINT# {Node} in {Mode} to {Value} sets the metering value run up on the device RESETMETER# {Node} {Node} to 0

3.6. Standard Command Set 100 nomos Documentation, Release 1.1.73

3.6.21 Philips HUE

Command set for the control of registered HUE components

Command Argument Description GETALLLIGHTS delivers a list of names of all the affiliated lights delivers a list of the IDs of all the affiliated GETALLLIGHTIDS lights RENAME# {Light},{Name} renames the {Light} as {Name} POWER_ON# {Light} turns {Light} on POWER_OFF# {Light} turns {Light} off changes the brightness of {Light} to SETBRIGHTNESS# {Light},{Value} {Value} - {‘Value} may be 0 to 255 changes the color tone of {Light} to SETHUE# {Light},{Value} {Value} - {Value} may be 0 to 65,535 changes the brightness of {Light} to SETSATURATION# {Light},{Value} {Value} - {‘Value} may be 0 to 255 changes the color temperature of {Light} to {Value} - {Value} depends upon the tar- SETCOLORTEMP# {Light},{Value} geted light and may at the moment be 153 - 500 (6500K - 2000K) carries out on {Light} a Color Loop or ends SETEFFECT# {Light}, COLORLOOP/NONE same carries out on {Light} a (SELECT) or several {Light},SELECT/ LSE- SETALERT# (LSELECT - for 30 seconds) “Breathe-Cycle” , LECT/NONE or it ends these (NONE) creates a new group with the Name {group} {group}, {light1}, {light2},..., CREATEGROUP and containing the Lamps {light1}, {lightx} {light2}... DELETEGROUP {group} deletes the Group {group} gives all the groups configued in the HUE GETALLGROUPS Bridge delivers a list of all the lamps assigned to the GETGROUPLIGHTS {group} Group {group}

3.6. Standard Command Set 101 nomos Documentation, Release 1.1.73

3.6.22 DEVICE (nomos App Command Class)

Command set for the DEVICE control (nomos APP)

Command Argument Description SETLANGUAGE# {Lang-Setting} selects a language for the speech output SETVOICE# {Voice} selects a voice for the speech output transmits {Text} to the device from which the ANSWER# {Text} last speech input came transmits {Text} to all devices, or to SAY# {Text},{Device} {Device} displays an instructional text on all devices, or NOTIFY# {Text},{Device} on {Device} displays an Alarm text on all devices, or on ALERT# {Text},{Device} {Device} loads anew the GUI on all devices, or to RELOAD# {Device} {Device} jumps back from the GUI into the System- RETURN# {Device} Selection menu on all devices, or {Device} switches the Screensaver OFF or after {Value} seconds on. The minimum time that SCREENSAVER# OFF/0/{Value} can be set is 2s. If a value or zero, {Value} 0 , is entered, the function behaves like OFF generates a Screensaver-Ticker {ID} with SETTICKERCONTENT {ID},{Content} [,{Value}] the description {Content} and the value {Value}. {Value} is optional REMOVETICKERCONTENT {ID} removes the Ticker {ID} displays the Ticker {ID} if the SHOWTICKERCONTENT {ID} SCREENSAVER is active

3.6. Standard Command Set 102 nomos Documentation, Release 1.1.73

3.7 Dynamic Classes

Dynamic class applies to special types of devices that come with a predeﬁned set of commands. Currently, the nomos system in this ﬁeld supports the REMOTE command set for the AppleTV as well as a rudimentary control of iTunes. The SONOS music players are also supported. It is important to note when using the remote class that malfunctions may sometimes occur after a software update (iTunes Version/ AppleTV Firmware). In such cases we strive to correct quickly. An improvement can only be made when this is still possible or when the manufacturer of the affected devices allows for this possibility. The nomos system AG makes no guarantee pertaining to legal claims arising from this characteristic!

3.7. Dynamic Classes 103 nomos Documentation, Release 1.1.73

3.7.1 Remote (iTunes/AppleTV)

Command set for the control of Apple Remote-compatible devices/software. This class is available only when the appropriate AddOn is also engaged. Additionally, the corresponding definitions file ../misc/remote.csv has to be defined for the AddOn. Detailed information for the application is found in the Chapter: Apple Remote Support

Command Argument Description delivers information on the current Player Sta- GETINFO tus NEXT jumps to the next title PREV jumps to the previous title PAUSE makes the current title pause PLAY plays the current title TOGGLEPLAY toggles between PLAY and PAUSE STOP stops the current title switches the Shufﬂe Mode of the current SETSHUFFLE# {ON/OFF} Playlist on or off SETREPEAT# {ONE/ALL/OFF} sets the Repeat Mode of the current Playlist SETPTIME# {1...x} jumps to the given playing time GETCTIME delivers the total play time in seconds GETPTIME reports the current playing time in seconds BUTTON_UP simulates a key stroke of the AppleRemote BUTTON_DOWN simulates a key stroke of the AppleRemote BUTTON_LEFT simulates a key stroke of the AppleRemote BUTTON_RIGHT simulates a key stroke of the AppleRemote BUTTON_SELECT simulates a key stroke of the AppleRemote simulates a key stroke of the AppleRemote BUTTON_SELECTLONG (Context Menu) BUTTON_MENU simulates a key stroke of the AppleRemote Expanded set of commands, not for connection - extended commands - through Home Sharing ADDIDTOQUEUE# {ID} attaches the ID x to the Up-Next-Queue ADDTITLETOQUEUE# {Name} attaches Title x to the Up-Next-Queue ADDARTISTTOQUEUE# {Name} attaches Performer x to the Up-Next-Queue ADDALBUMTOQUEUE# {Name} attaches Album x to the Up-Next-Queue CLEARQUEUE erases Up-Next Queue DISABLEALLSPEAKERS turns off all audio output devices DISABLESPEAKER# {Speakername} turns {Speakername} off ENABLEALLSPEAKERS turns on all audio output devices ENABLESPEAKER# {Speakername} turns {Speakername} on GETALLALBUMS provides a list of all albums GETALLARTISTS provides a list of all performers GETALLIDSOFPLAYLIST# {Playlist} delivers all IDs in {Playlist} (max. 250) GETALLTITLESOFPLAY {Playlist} gives all titles in {Playliste} (max. 250) LIST# GETALLARTISTSOFPLAY gives all performers in {Playliste} (max. {Playlist} LIST# 250)

3.7. Dynamic Classes 104 nomos Documentation, Release 1.1.73

Command Argument Description GETALLALBUMSOFPLAY {Playlist} lists all albums in {Playliste} (max. 250) LIST# GETALLPLAYLISTS delivers a list of all the Playlists on hand GETIDALBUM# {ID} lists the album with the assigned {ID} GETIDARTIST# {ID} lists the performers on the speciﬁed {ID} GETIDTITLE# {ID} gives the title with the given {ID} furnishes a list of all recognized audio output GETSPEAKERLIST devices gives the status (ON or OFF) of GETSPEAKERSTATE# {Speakername} {Speakername} gives the volume of an Airtunes loudspeaker GETSPEAKERVOL# {Name} with reference to the Master Volume gives the current sound volume of the applica- GETVOL tion PLAYID# {ID} plays the title {ID} PLAYPLAYLIST# {Name} plays the Playlist {Name} SEARCHALBUM# {Album} lists all IDs, which belong to {Album} reports a list of the performers, who are in- SEARCHARTIST# {search string} cluded in the search string (Limit: 50) delivers a Track-ID list of the titles, which con- SEARCHTITLE# {search string} form to the search string (Limit: 50) sets the sound volume of an Airtunes loud- SETSPEAKERVOL# {Name}, {Value 0-100} speaker with reference to the Master Volume SETVOL# {0...100} sets the volume, 0 to 100%

There are corresponding SYS commands for this:

Command Argument Description gives a list of all devices deﬁned in the GETREMOTEDEVICELIST remote.csv starts {ON} /ends {OFF} the Pairing Mode for REMOTEPAIRING# {ON}/{OFF} iTunes and AppleTV in the remote class

3.7. Dynamic Classes 105 nomos Documentation, Release 1.1.73

3.7.2 Sonos

Set of commands for controlling SONOS Streaming Players. This class is available only when an appropriate AddOn is also engaged. In addition, the corresponding definitions file ../misc/sonos.csv has to be defined for the AddOn . Detailed information for the application may be found in the Chapter: SONOS Streaming Player Support

Command Argument Description PLAY plays the current title PAUSE makes the current title pause STOP stops the current title NEXT jumps to the next title PREV jumps back to the previous title

JUMPTOINDEX# {1...x} jumps to the x title in the queue gives the current sound volume of the applica- GETVOL tion SETVOL# {0...100} sets the volume, 0 to 100% SETBALANCE# {-100...0...100} sets the balance (-100) left - (+100) right GETBALANCE delivers current balance MUTEON muting switched ON MUTEOFF muting switched OFF LOUDNESSON Volume ON LOUDNESSOFF volume OFF SETTREBLE# {-10...0...10} EQ sets the treble SETBASS# {-10...0...10} EQ sets the bass SETPTIME# {seconds} jumps to the given playing time GETPTIME reports the current playing time in seconds GETCTIME delivers the total play time in seconds switches the Repeat Mode of the current playlist SETREPEAT# {ON/OFF,1/0,YES/NO} on or off switches the Random Mode of the current SETSHUFFLE# {ON/OFF,1/0,YES/NO} playlist on or off switches Cross-fade Mode of the current SETCROSSFADE# {ON/OFF,1/0,YES/NO} playlist on or off. GETALLPLAYLISTS delives a list of all playlists on hand erases the queue and immediately plays Playlist PLAYPLAYLIST# {Name} {Name} includes Album {Name} at the end of the ENQUEUEPLAYLIST# {Name} queue GETALLTITLESOFPLAY {Name} reports all titles on the Playlist {Name} LIST# GETALLARTISTSOFPLAY {Name} gives all performers on the Playlist {Name} LIST# GETALLALBUMSOFPLAY {Name} lists all albums on the Playlist {Name} LIST# GETALLALBUMS gives a list of all albums erases the queue and immediately plays Playlist PLAYALBUM# {Name} {Name}

3.7. Dynamic Classes 106 nomos Documentation, Release 1.1.73

Command Argument Description includes Album {Name} at the end of the ENQUEUEALBUM# {Name} queue GETALLTITLESOF ALBUM# {Name} gives all titles of the Album {Name} GETALLARTISTSOF AL- {Name} gives all performers in Album {Name} BUM# GETALLFAVORITES gives all favorites PLAYFAVORITE# {Name} plays the Favorite {Name} immediately GETALLTITLESOFQUEUE gives all titles in the queue GETALLARTISTSOFQUEUE gives all performers in the queue GETALLALBUMSOFQUEUE lists all the albums in the queue CLEARQUEUE deletes content of queue LEDON turns on the LED of the Sonos device LEDOFF turns off the LED of the Sonos device includes an additional Sonos device with the Class Name {Name} as a replay device (source ADDMEMBER# {Name} synchronizing), “x” has to be deﬁned in the sonos.csv. REMOVEMEMBER# {Name} removes the Sonos device with that class name streams the signal from the Line-In Port to the STARTLINEINSTREAM# {Name} device with the class Name “x”; “x” has to be deﬁned in the sonos.csv STOPLINEINSTREAM# {Name} stops the stream to Device “x” PLAYLINEIN plays the signal locally from the Line-In Port -15 - (+)15 - attunes the sensitivity of the Line- SETLINEINLEVEL# {-15 - 15} In Port to the analoge source delivers the selected sensitivity of the Line-In GETLINEINLEVEL Port

3.7. Dynamic Classes 107 nomos Documentation, Release 1.1.73

3.7.3 XBMC

Set of commands for controlling XBMC Clients. This class is available only if the appropriate AddOn is engaged. The deﬁnition ﬁle ../misc/ xbmc.csv corresponding to the AddOn also has to be present. Detailed information on the application can be found in the Chapter: SONOS Streaming Player Support

Command Argument Description SHUTDOWN shuts system down SUSPEND suspends running of system HIBERNATE activates hibernate mode REBOOT reboots system PLAYFILE# {File} or {URL} plays the given source forthwith PLAY plays the current title PAUSE temporarily interrupts replay STOP stops the replay NEXT jumps ahead to next title PREV jumps back to previous title FASTFORWARD fast forward REWIND fast rewind BUTTON_UP simulates key stroke „Cursor up“ BUTTON_DOWN simulates key stroke „Cursor down“ BUTTON_LEFT simulates key stroke „Cursor left“ BUTTON_RIGHT simulates key stroke „Cursor right“ BUTTON_SELECT simulates key stroke „Enter“ BUTTON_BACK simulates key stroke „Backwards“ BUTTON_HOME simulates key stroke „Home“ BUTTON_INFO simulates key stroke „Info“ BUTTON_MENU simulates the key stroke „Menu“ SETVOL# {0-100} Sets the sound volume to 0-100% GETVOL queries the current sound volume SETREPEAT# {ALL/ONE/ON/OFF} switches the repeat mode of the current title SETSHUFFLE# switches the random mode of the current title MUTEON muting ON MUTEOFF muting OFF GETMUTE queries the muting state SETPTIME# {Seconds} jumps to the given play time GETPTIME delivers the current play time in seconds GETCTIME gives the entire playing time in seconds SHOWMESSAGE# {Message} displays {Message} on the viewing screen — Movies — delivers a list of all the movie IDs available in GETALLMOVIEIDS the library PLAYMOVIEID# {Movie-ID} plays {Movie-ID} GETMOVIEIDTITLE# {Movie-ID} gives the title of the {Movie-ID} — PVR Channels — GETALLCHANNELIDS delivers a list of all Channel IDs

3.7. Dynamic Classes 108 nomos Documentation, Release 1.1.73

Command Argument Description PLAYCHANNELID# {Channel-ID} switches to the station with {Channel-ID} delivers the name of the broadcasting station of GETCHANNELIDNAME# {Channel-ID} {Channel-ID} delivers status information (identical to Broad- GETINFO cast) — Performers — GETALLARTISTIDS gives a list of artists’ IDs for all performers GETARTISTIDNAME# {Artist-ID} lists the performers for the {Artist-ID} PLAYARTISTID# {Artist-ID} plays all songs from {Artist-ID} GETSONGIDSOFARTISTID# {Artist-ID} lists song IDs for all songs by {Artist-ID} — Albums — GETALLALBUMIDS gives a list of album IDs of all albums lists the name of the album for the GETALBUMIDNAME# {Album-ID} {Album-ID} PLAYALBUMID# {Album-ID} plays the album with the {Album-ID} lists song IDs of all songs in the album GETSONGIDSOFALBUMID# {Album-ID} {Album-ID} — Songs — GETALLSONGIDS gives a list of song IDs of all songs GETSONGIDTITLE# {Song-ID} gives the title of {Song-ID} GETSONGIDARTIST# {Song-ID} gives the performer of {Song-ID} GETSONGIDALBUM# {Song-ID} delivers the album with {Song-ID} PLAYSONGID# {Song-ID} plays {Song-ID} immediately — Audio Playlist — GETSONGIDSOFAUDIO delivers a list of all {Song-IDs} in the audio PLAYLIST playlist (equivalent of the audio queue) PLAYAUDIOPLAYLIST plays the audio playlist CLEARAUDIOPLAYLIST deletes the audio playlist ADDSONGIDTOAUDIO {Song-ID} adds {Song-ID} to the audio playlist PLAYLIST# ADDALBUMIDTOAUDIO adds all titles of {Album-ID} to the audio {Album-ID} PLAYLIST# playlist ADDARTISTIDTOAUDIO adds all titles of {Artist-ID} to the audio {Artist-ID} PLAYLIST# playlist — Video Playlist — GETMOVIEIDSOFVIDEO delivers a list of all {Movie-IDs} in the video PLAYLIST playlist (equivalent of the video queue) PLAYVIDEOPLAYLIST plays the video playlist CLEARVIDEOPLAYLIST deletes the video playlist ADDMOVIEIDTOVIDEO adds {Movie-ID} to the video playlist PLAYLIST — Search Functions — seeks {Title} and delivers a Song-ID list of SEARCHTITLE# {Titel} all those found (initial letters sufﬁce) seeks {Performer} and delivers a SEARCHARTIST# {Performer} performer-ID list of all those found (initial letters sufﬁce)

3.7. Dynamic Classes 109 nomos Documentation, Release 1.1.73

Command Argument Description seeks {Album} and delivers an Album-ID list SEARCHALBUM# {Album} of all those found (initial letter sufﬁces) seeks {Film Title} and delivers a Movie- SEARCHMOVIE# {Film Title} ID list of all those found (initial letters sufﬁce)

3.7. Dynamic Classes 110 nomos Documentation, Release 1.1.73

3.8 Keyboard Layout (special keys)

For processing the deﬁnition tables described in the following material, characters that are not found in the keyboard layout of the Mac System are sometimes needed. The following table provides a printout of the important characters, those that will be needed and how to obtain them:

@ MacOS = [ALT]+L | MacOS = [ALT]+7 [ MacOS = [ALT]+5 ] MacOS = [ALT]+6 { MacOS = [ALT]+8 } MacOS = [ALT]+9 \ MacOS = [ALT]+[SHIFT]+7 - @ WinOS = [CTRL]+[ALT]+Q | WinOS = [CTRL]+[ALT]+< [ WinOS = [CTRL]+[ALT]+8 ] WinOS = [CTRL]+[ALT]+9 { WinOS = [CTRL]+[ALT]+7 } WinOS = [CTRL]+[ALT]+0 \ WinOS = [CTRL]+[ALT]+ß

The Apple Keyboard makes a distinction on the keyboard between the [ALT] key left and the [ALT] key right alongside the space bar. This means that one can dispense with hitting the [CTRL] key as well when using the righthand [ALT] key under WINDOW.

3.8. Keyboard Layout (special keys) 111 CHAPTER 4

Expanded Functions (AddOn’s)

CommandServer Extension GIRA Homserver KO-Gateway, KNXnet/IP Support Event Servers eyeTV - Streaming Support Apple Remote Support Sonos Streaming Player Support Z-Wave Support Philips HUE Support mremote Support (commandFusion iViewer support)

The nomos system is constructed with modules and can be expanded nearly at will to incorporate functions. The system’s own protocol interfaces can also be defined and incorporated in this way with so-called Com- mandServer Add-on’s. More complex interfaces, such as those for KNX, Z-Wave, SONOS or the Control System Protocol of Commandfusion, are available as ready-made modules. Please note that appropriate licensing is also required as a rule for the use of those modules. All these modules expand the scope of commands of the nomos system accordingly and make possible the employment of the nomos system as an overarching control center or as a multi-protocol gateway, enabling all collaborating systems to communicate with one another by means of a uniform, rudimentary ASCII protocol. All these modules and interfaces are made transparent, as described later, and can be changed, tailored and also expanded as desired by the user. The descriptions of the definition files that will follow are prepared in the .csv format. Strict adherence should be made to the respective configuration options for the various files. The semicolon is the correct sign for separating the respective functions within a line. The end of each line of definition should also conclude with a semicolon. Take care that the end of the line is then terminated with a Line Feed or Return. It is recommended that the files be adequately documented. A commentary text at the start of the line or at the end of the line can be used for this purpose.

// This is a commentary A simple commentary text at the beginning of the line

112 nomos Documentation, Release 1.1.73

1;1;; // New Start of the Daemon A simple commentary text at the end of the line. Take care here that at least one tabulator is set in front of the commentary marker „//“.

/* Supported EIS Types in the esf file EIS 1 ’Switching’ (1 Bit) EIS 2 ’Dimming - position’ (1 Bit) EIS 2 ’Dimming - control’ (4 Bit) EIS 2 ’Dimming - value’ (8 Bit) EIS 3 ’Time’ (3 Byte) EIS 4 ’Date’ (3 Byte) EIS 5 ’Value’ (2 Byte) */ multiline commentary is set off with "/*" und "*/". at the end of the documentation, all the definition files are attached for sourcing reference Should the module fail to work as desired after its configuration, a look at the Startlog is recommended. The Log reveals whether the various files could be correctly read in and whether the corresponding module was activated. Example of the Startlog output of the remote.csv

Example of the Startlog output of a CommandServer (LG1.csv)

113 nomos Documentation, Release 1.1.73

4.1 CommandServer Extension

Structure of the CommandServer Deﬁnition Tables Reserved (extended) server types Employment of USV/RS232 converters

The CommandServer serves to work with protocols of additional devices by means of the command set of the nomos system. If, for example, along with the steering of the nomos system control, it also becomes necessary to integrate into the controls additional peripherals, such as a multiroom audio system, a possible TV system, a projector or an IR Emitter. The nomos System can also be deployed as a complex control center in this way. Primarily, the integration of such systems is greatly simplified for the user with this technology because he then needs only to concern himself with the command set of the nomos system. Already available CommandServer definition files are there to be freely downloaded from our Hompage www.nomos-system.com . The offering of definition files is continuously expanded. The nomos system’s master license (Gate) comes with a CommandServer license. This means that an external device can be controlled, namely a CommandServer definitions file can be processed. The nomos system Gate+ License encompasses more than 10 CommandServer licenses and can be expanded to a maximum of 25 CommandServer licenses (nomos Box and Mac OSX). The nomos system determines at the Start of Services whether definition files are available. As long as corresponding entry items are found, the command chains are integrated and made available for controlling. Please take care that the number of definition tables in the respective indices does not exceed the number of licensed CommandServers; nomos engages the tables sequentially. This means that the tables are read in the order they are presented as available by the data system on the basis of the names they are given. When the number of tables becomes greater than the number of licenses, additional tables are disregarded. Information on the files that are read in is given by the Startlog. Please be careful when choosing the .csv names not to use class designations (SYS, BROWSER, ITUNES,TV, ...) that already exist. so as to ensure an unmistakable assignment of the CommandServer class.

4.1. CommandServer Extension 114 nomos Documentation, Release 1.1.73

After the deﬁnition tables are read in, the command classes are extended by the content of their deﬁnition tables. The output of all available CommandServers can also be initiated on command: Query of the currently available CommandServer classes Answer: GETSRVLIST=IRT_SAM|NUVO|PROWL|TEMP|YAHOO|OK The typical answer might say that 5 additional classes are available. The “Commands” of the respective classes can also be called up. When the CommandServer classes are known, the respective commands can also be called up. Available for each CommndServer class is a Command <[CLASS]> . Query of the currently available commands of the CommandServer class

Answer: GETCMDLIST=POWER_TOGGLE | OFF | ON | VOL- | VOL+ | TOG- GLE_MUTE | PROG- | PROG+ | P.MODE | S.EFFECT | S.MODE | SOURCE_TOGGLE | TV | AV | S-VID | HDMI1 | HDMI2 | EXT1 | EXT2 | COMP | PC | WISELING_TOGGLE | TEXT | KEY_-/-- | KEY_00 | KEY_01 | KEY_02 | KEY_03 | KEY_04 | KEY_05 | KEY_06 | KEY_07 | KEY_08 | KEY_09 | KEY_BLUE | KEY_GREEN | KEY_YELLOW | KEY_RED | KEY_UP | KEY_DOWN | KEY_LEFT | KEY_RIGHT | KEY_MENU | KEY_EXIT | KEY_RETURN | PLAY_PAUSE | STOP | REW | FF | HELP | PIP | CH.MGR | MOVE | P

The typical answer provides a list of all available commands of this class. If a

4.1. CommandServer Extension 115 nomos Documentation, Release 1.1.73

command contains at its end a „#“ . such as with ...|VOLUME#|REW|... , this means that a Value <[CLASS]> has to follow the command.

4.1. CommandServer Extension 116 nomos Documentation, Release 1.1.73

4.1.1 Structure of the CommandServer Deﬁnition Tables

As just described, CommandServer offers the possibility to merge all kinds of systems into the nomos system. The CommandServer also works simultaneously here as a protocol transformer, which integrates the specific protocol of the external systems into the nomos system’s protocol structure. The CommandServer works in two directions. It processes incoming as well as outgoing protocol sequences. A highly efficient integration of external protocols is accomplished through the simple structure of the definition files. Nearly all types of protocols can be processed with this. The CommandServer definition files are read in and made ready when the nomos System is started. If no startup command (STARTUPCMD) is defined, a connection to the target system is initiated after the first command sequence is set forth. If reports (Events) from the external system are to be processed, it is necessary to establish a durable connection. This can be achieved accordingly with, for example, the Parameter TIMEOUT/TIMEOUT_IN_MS. In the [CONFIG] Section, several other possibilities are at hand for individually manipulating the behavior of the communication interface. The possible and available parameters of the definition file are also reported in the Start Log when the DEBUG option is set. The output serves for information and assistance in case of defective behavior

If a CommandServer from nomos system is rejected, this will also be reported in the Start Log.

Structure of the deﬁnitions table:

Type: csv ﬁle Location: .{projectPath}addon Name: [CLASS].csv Length: 2,000 lines/entry items per section Event: - Export: yes

4.1. CommandServer Extension 117 nomos Documentation, Release 1.1.73

License: yes

The [CLASS].csv consists of 3 Sections: [CONFIG]; general configuration of the interface parameter [COMMAND]; Definition of the relevant protocol sequence and assignment of the command names [MAPPINGS] Event definitions of possible answering sequences Structure: Introduce into the \{projectPath}\addon\ folder a {ClassName}.csv with the following content. The file name defines the class name. Take care that the class name chosen for use is not yet recognized by the nomos System: • [CONFIG];Section ACTIVE; activates/deactivates the Webserver „YES“ (default)= active, DEBUG; Expanded LOG output „YES“ = active, „NO“ (default) = not active SERVERIP; {Device-IP}; or LOCAL for USB/RS232 operation. This Parameter is a perequisite. SERVERPORT; {TCP/UDP/AUTO Device-Port}; or, when using USB/RS232 adapters, AUTO or Serial Port; {baud rate}; {databits}{parity}; {Stopbits}; {flow control}. This Parameter is indispensable; with serial Command Servers with SERVERPORT;AUTO the hardware ports are initially used if they are present SERVERPROTOCOL; Protocol: "UDP", "TCP" , “HTTP“ , “HTTPS“ or „SERIAL“ for USB/RS232 adapter. Default = "UDP" SERVERMODE; Transmission type: "ASCII" or "HEX" . This Parameter is absolutely necessary. SERVERTIMEOUT_IN_MS; Time (in ms), while waiting for a possible answer. 0 = don’t wait, NONE = durable connection maintained when SERVERTIMEOUT;NONE is defined, the connection is sustained after a command is issued and the data arriving of the device is interpreted (comparable Eventserver). This functions with UDP,TCP and serial connections. Timeout can also be further defined as command responsive. MATCHING; Setting of the procedure for parsing the "MAPPINGS NORMAL“ (default) or „FULL“ EXPORT CommandServer clearance/sharing active „YES“ = active, „NO“ (default) = not active

4.1. CommandServer Extension 118 nomos Documentation, Release 1.1.73

CLIENTIP; {Device-IP}: gives another IP to which the reply of the CommandServer is directed. CLIENTPORT; {Device-PORT}: gives the Port of the CLIENTIP to which the reply should be sent. CLIENTIP and CLIENTPORT must both be defined LOCALPORT; Manual prompt of the local source port for the connection. Possible values: RANDOM or 1..65535 ; if LOCALPORT is now defined, the local port automatically corresponds with the SERVERPORT (as in previous). Should the source port already be in use, a source port is automatically chosen at random and a Log entry is written SERVERTIMEOUT; Like SERVERTIMEOUT_IN_MS , except time (in s), during which a possible answer is awaited. When SERVERTIMEOUT and SERVERTIMEOUT_IN_MS are both already defined, the setting for SERVER-TIMEOUT_IN_MS takes precedence. SERVERTYPE; Definition of the CheckSums rule (HEX CommandServer), applied accordingly during employment. If a rule is defined, the protocol sequence is augmented correspondingly. Firmly embedded rules for specific protocols also exist along with rules that can be freely defined. RUS for the Russound RNet protocol SPEAKERCRAFT for products with the same name. ADNOTAM for products with the same name. SUM= {Index Startbyte}-{Index Endbyte} calculates the Lowbyte of the sum of {Index Startbyte} through {Index Endbyte} and adds this to the end of the protocol sequence. The indices are optional. The option can only be used in HEX mode. Examples: (exit sequence: 0102030405)

- SUM : 01020304050F - SUM=1 : 01020304050F - SUM=2 : 01020304050E - SUM=1-5 : 01020304050F - SUM=2-4 : 010203040509

STARTUPCMD; executes {command} once at the Start of the CommandServer. The commands being used have to be defined under [COMMANDS]; . Several commands can be lined up by means of „,“ , for example, : {1stCommand},{2ndCommand},{3rdCommand} . All rules (Prefix, Suffix, Checksumme, etc.), which happen to be current, apply to those commands being employed. Example: STARTUPCMD;POWER_ON,STATE sent at the Start of the CommandServer. The commands POWER_ON and STATE , as defined under [COMMANDS].

4.1. CommandServer Extension 119 nomos Documentation, Release 1.1.73

HEARTBEATCMD; {HeartbeatCMD};{Heartbeatinterval}; executes the command {HeartbeatCMD} in the time interval {Heartbeatinterval} with spacing in seconds; if no time is given for {Heartbeatinterval} , the default setting of 60s applies. For the {HeartbeatCMD}, the applicable conditions are as those for STARTUPCMD . Only one command can be set, however. The HEARTBEATCMD is executed only when a connection to the target system exists. RECONNECT restores the connection again after a transmission fails one time. „YES“ = active, „NO“ (default) = not active Prerequisites: a) STARTUPCMD is deﬁned b) A durable connection has been established CMDPREFIX; augments the Kommando/protocol output with corresponding characters at the start of the chain of characters. Not to be used if SERVERTYPE is set. CMDSUFFIX; augments the Kommando/protocol output with corresponding characters at the end of the chain of characters. Not to be used when SERVERTYPE is set. SEQUENZPREFIX like CMDPREFIX , except it takes effect at the beginning of the entire protocol sequence. Not to be used when SERVERTYPE is set. SEQUENZSUFFIX like CMDSUFFIX , except it takes effect at the end of the entire protocol sequence. Not to be used when SERVERTYPE is set.

STARTDELIMITER, ENDDELIMITER {Zeichen - oder Bytesequenz} The Delimiters intervene immediately upon receipt of a (partial-)sequence and only hand over the complete reception sequence (which can consist of several partial sequences) to the Matching Engine when the condition is met or the conditions are met. The Log output is expanded accordingly. If the Standard Reception Buffer (8K) is too small, it is dynamically enlarged in 8K steps. It also makes sure that each part of a received sequence is transmitted separately to the Matching Engine when this sequence fulfills the Delimiter conditions multiple times. It is sufficient to report either one of the two Delimiters. MAPPREFIX; inserts a corresponding character (analog to CMDPREFIX ) before every Mapping entry MAPSUFFIX; inserts an appropriate character (analog zu CMDSUFFIX ) after each Map- ping entry SPACING; Fixes the minimum temporal spacing {Zeit in ms} (time in ms) between 2 command sequences. Limits in this way the transmission cycle between the protocol sequences to a defined value. This can be helpful, for example, when issuing IR commands. USERNAME; Reporting of user’s name, when necessary PASSWORD; Reporting of password, when necessary ENCRYPTION; reserved, at the moment without a function

4.1. CommandServer Extension 120 nomos Documentation, Release 1.1.73

Example for the use of the xxxPREFIX/SUFFIX option: CMDPREFIX;A ; CMDSUFFIX;E SEQUENZPREFIX;X SEQUENZSUFFIX;Z

[COMMANDS]; POWER_ON;01 ; HDMI1;02 ; SC_DIGITAL;03 ;

Following exemplary command sequence: <{CLASS}> creates the following output: XA 01EA 02EA 03EZ

• [COMMANDS];Section - command definitions Structure of command definition: {CMD};{Sequenz};{Command Timeout[ms]};{Paramteter}; The command definitions assign to a sequence {Sequenz} to be transmitted a freely definable command {CMD}; the sequence is given in appropriate (ASCII/HEX) format. The following special characters can appear in the {Sequenz} : "\#" inserts the Argument conveyed with {CMD} to the corresponding position in {Sequenz}. The Argument is inserted in the ASCII mode without further transformation; the Argument in the HEX mode is transformed with prefixes (1 Byte) and inserted thereafter. Several Arguments can be transmitted when set apart by commas. The Sequence is structured by the order in which commands are issued and transmitted following termination of the class. {CMD}; Freely definable command name under which the transmission of the protocol sequence is triggered. {Sequence}; Assigned protocol sequence that is transferred to the target system when the appropriate command is issued. {Command Timeout[ms]} Timeout Option, which can be assigned individually to every command. The setting of this option disregards the global Timeout setting in the [CONFIG] section. If commands are lined up in a chain within a sequence, the command Timeout, if defined, applies to the last command.

4.1. CommandServer Extension 121 nomos Documentation, Release 1.1.73

{Paramteter}; setting additional option for the manipulation of the value transfer "\#" . See also format options or conditions/comparing system.

Examples for possible deﬁnitions [COMMANDS]

SERVERMODE; ASCII SWITCH;TURN_ON_THE_\#-CHANNEL RECORD;_AND_RECORD_\#_AND_\#

the commands: <[CLASS]><[/CLASS]>

generating the following sequence: „TURN_ON_THE_ZDF- CHANNEL_AND_RECORD_ARD_AND_RTL“ Characters that cannot be displayed can also be transferred to the ASCII string. These characters are also embedded like an Argument. Please note that only one character can be transferred in each instance. These characters are transferred as follows: SWITCH;SCHALTE_AUF_DEN_\#-KANAL\0x0D\0x is herewith the wildcard for following HEX Bytes, 0D is the Byte to be sent (in this case a line prompt or RETURN). Please note that the wildcard should be used with each Byte. Namely, \0x0D\0x0C\0xFF ... and so forth.

SERVERMODE; HEX SWITCH;07AB\#04; RECORD;07CF\#BD\#06;

the commands: <[CLASS]>

generating the following sequence: 07AB010407CFFFBD0206

SERVERMODE; HTTP/HTTPS PLAY;/cgi-bin/vcontrol?command=play; STOP;/cgi-bin/vcontrol?command=stop;

the commands: <[CLASS]>

generating the following sequence: GET /cgi-bin/vcontrol?command=play HTTP/1.1 The Server mode HTTP serves, for example, for contacting devices that have a CGI interface or a WEB interface. Web queries can also be generated with this. As soon as the format options for a command are deﬁned and the HEX Mode is active, the implicit automatic Argument transformation for this command is turned off. Should a Hex transformation still be sought, the formater %hex should be used. Various examples for the application of format options VOLUME;;;{%-20} Subtracts 20 from every transferred (decimal-)Argument before the Argument is deployed in the Sequence. TEMPSET;!SET_C\#;20;{%*1.00} Scales the transferred value to two places after the decimal point; a Timeout command of 20ms is also deﬁned here.

4.1. CommandServer Extension 122 nomos Documentation, Release 1.1.73

CFG_INITVOL(V);INIVOL\#\x0D;;{%-100,%*-1,%/1.2658,%*1} Scales a value transfer for regulating sound volume. The deﬁnition of the manufacturer describes a value range of 0 - 79 decimal, with the Value 0 deﬁning the maximum volume. The computing rule works here as follows: with \# transferred Value: 10

- 10 -100 = -90 - -90 *-1 = 90 - 90 / 1.2658 = 71,10128 - 71,10128 *1 = 71

The nomos system scales the product of a multiplication to the decimal places of the multiplier. If the multiplier is *1, namely without decimal places, the product isf a whole number. • [MAPPINGS](optional) Interpretation of the protocol return sequence {MapString};{Description};{Action};ONCHANGE;{Condition} {Map String} Arriving string, which can be evaluated with the use of the parsing options. When used without parsing, the condition is met when the arriving string = {Map String} . When parsing is used, the condition is met when a successful match takes place. The content of the Parsing Option is transferred as Argument. {Description} Designator for the result of the successful Match. The Argument is automatically included {Action} nomos command chain or Script, which is suppsoed to be carried out upon successful Match. ONCHANGE The Option ONCHANGE is used when the value is supposed to be sent only upon changes in value. If the field remains empty, the value is always sent. {Condition} When defined, the previous action is only executed if the condition is met. The comparative logic symbols ( „>“,“<“,“=“ ) can be employed. Also, such combinations as „<>“ (unequal) or „>=“ (greater than or same) can be defined. The arriving string {Map-String} is searched for the following conditions and transmits the discovered character chain (Match) as Argument to the field {designation}. In {designation} a freely definable string can also be entered as a normal text designation (see Example). Entered in {Action} is the nomos command chain and/or Script, which results in execution when the {condition} is fulfilled. The following special characters can be used in {Map String} as an Option for the Matching or Parsing: Parse/Match Options \^ Matches a character exactly and adds the Argument. \? Matches a character exactly and disregards it (Wildcard) \^ and \? may appear at any desired spot

4.1. CommandServer Extension 123 nomos Documentation, Release 1.1.73

\* Wildcard Match and adds the Argument \% disregards any amount of characters \!{number}! skips over this number {number} of places. {number} , the number, may have a maximum of four zeros and has to be given in decimal system. Exercise care that a Byte corresponds to two places with a HEX Match. Further rules: Combinations of \^ and \? are possible in any desired length. Thus, for example, deﬁnitions like \^^^^ for 4 characters. If \^ and/or \* are used in combinations, the Argument is augmented by the respective characters. The entry items in the MAPPINGS segment are processed line by line according to the Switch MATCHIN;NORMAL (Residual string after match) or MATCHING;FULL (entire arriving string). With a Match MATCHING;NORMAL additional entry items are disregarded and the characters remaining in the return sequence are evaluated anew. It is therefore sensible to reposition long. complex Match-Strings to the beginning of the Mapping region in order to assure a clear interpretation. In the ASCII mode the Argument is added without further transformation; in the HEX mode the Argument is converted to decimals and then added. Hex values (e.g. "0x0D", just as in the COMMANDS region) can also occur and can be matched. Example (SERVERMODE;HEX): 07AA\##??;VOLUME 07EF\##04;CHANNEL The return sequence: 07EF040407AA1008 creates the following normal text sequence: <[CLASS]> Example (SERVERMODE;ASCII): TITLE=\*|;TITLE The return sequence: TITLE=When the dog barks|ALBUM generates the following normal text sequence: <[CLASS]> Example (SERVERMODE;ASCII) Extended: \%VOL=\*|;VOLUME;;;<=5 The return sequence: GETVOL=EXT|VOL=4|... generates the following normal text sequence: <[CLASS]> and simultaneously triggers the screen saver, hence the Argument <=5 Example (SERVERMODE;HTTP): standby\*;STANDBY The return sequence: standbyon generates the following normal text sequence: <[CLASS]>STANDBY=ON

4.1. CommandServer Extension 124 nomos Documentation, Release 1.1.73

As soon as a single MAPPINGS line exists, content of the return sequence that cannot be evaluated is suppressed. This makes possible the extraction of only the relevant data from the return sequence, without having to enter deﬁnitions for all possible combinations. If no MAPPINGS segment exists, raw output is reported. Communication can be monitored at all times in raw format (namely, after the transformation and before the reconversion) with the Logging Monitor.

for more complete understanding, we shall proceed with the structure of a table for a LINN ampliﬁer in the context of a simple deﬁnition table. Linn.csv

[CONFIG] SERVERIP 192.168.50.201 SERVERPORT 4001 SERVERMODE ASCII SERVERTIMEOUT 0 [COMMANDS] OPEN $OPEN$\x0d\x0a CLOSE $CLOSE$\x0d\x0a PLAY $PLAY$\x0d\x0a PAUSE $PAUSE$\x0d\x0a STOP $STOP$\x0d\x0a FWD $SKIP +$\x0d\x0a PREV $SKIP -$\x0d\x0a MUTEON $MUTE\x20ON$\x0d\x0a MUTEOFF $MUTE\x20OFF$\x0d\x0a VOL+ $VOLUME\x20+$\x0d\x0a VOL- $VOLUME\x20-$\x0d\x0a SRC_DISC $LISTEN\x20DISC$\x0d\x0a SRC_DIG1 $LISTEN\x20DIG1$\x0d\x0a SRC_AUX1 $LISTEN\x20AUX1$\x0d\x0a SRC_AUX2 $LISTEN\x20AUX2$\x0d\x0a SRC_TV $LISTEN\x20TV$\x0d\x0a SRC_VCR $LISTEN\x20VCR$\x0d\x0a SRC_MAIN $LISTEN\x20MAIN$\x0d\x0a GET_MODE $MODE$\x0d\x0a

As previously described, the [CONFIG] segment contains the settings for the conﬁguration of the communication parameter of the device to be controlled. Since the LINN Unidisc has no network interface, a

4.1. CommandServer Extension 125 nomos Documentation, Release 1.1.73

MOXA LAN/RS232 Adapter was deployed here. The Moxa was given the IP Address 192.168.50.201 and the Port was set at 4001. The LINN Protocol is a pure ASCII protocol. Feedback is not quantified (TIMEOUT=0) . The absence of the settings SERVERPROTOCOL means that the UDP Protocol (Standard) is engaged. Since this protocol contains no rule for calculating the Checksum, the entry item SERVERTYPE is missing. Now the actual commmands are entered in the [COMMANDS] region. In keeping with the manufacturer’s documentation, the following command chain has to be transmitted to the LINN in order to open the drive train: $OPEN$\x0d\x0a Thereafter, this command should be made available to the nomos Protocol under . The same procedure is used with all the other necessary commands. Once the table is prepared and included in the corresponding index of your nomos system, the nomos Service has to be started anew or a „RESET“ triggered through the nomos Scripting Client. Thereafter, you execute the Command „AddOn Commands laden“ (i.e. load add-on commands) in the file dialog. Select only the Class „LINN“ , which was defined with the file name of the definition table, and observe the new commands. In lieu of the nomos Scripting Client, you can also send the command sequence with a simple terminal program (e.g., NetCAT or Hyperterminal). The nomos Wizard also offers the possibility to send command sequences manually.

You will notice, for example, in the Scripting Client that all commands are now part of the CommandServer deﬁnitions table. Now select „open“ and include this in the „String to send“ mask.

4.1. CommandServer Extension 126 nomos Documentation, Release 1.1.73

Send the command to your nomos system and observe the entry item which then appears in the Logging Monitor of the Scripting Client.

You will see that nomos treats those data in accordance with the settings of the deﬁnitions table and sends the required data packet to the assigned target address. We shall now elucidate further possibilities of the [MAPPINGS] deﬁnitions as follows: data: \x0D\x0Astatus tv off pipoff recoff\x0D\x0A> Reception sequence, which is received upon turning on the device [MAPPINGS]

status \* ;POWERMODE;;NOCACHE Matches to the character chain „tv“ and transfers the content as value for POWERMODE (POWERMODE=tv) . Since a Match takes place, namely the match condition is fulﬁlled, the local action is executed. A script is carried out with the local action. The script name is now expanded by the content of the match to LOEWE_MEDIEN_tv.myh and executed accordingly. The output results from every received Event ( NOCACHE ). status \% \* ;SUBMODE Match to the character chain, which is received between the second and third blank spaces after „status“. In this case, that is the Value „off“. This value is labeled as SUBMODE and reported accordingly as SUBMODE=off . The output occurs only with a value change. ( NOCACHE not set) status \% \% \* ;PIPMODE As in the previous example, except that the chain of characters between the third and fourth blank characters after „status“ are matched and occupy PIPMODE with the appropriate content PIPMODE=pipoff status \% \% \% \*\0x0D;RECMODE As with the previous, except that the match to the character chain occurs after „status“ between the fourth blank character and the \0x0D and occupies RECMODE with the corresponding content RECMODE=recoff Once the protocol sequence is run through completely and evaluated, this translated report is issued: POWERMODE=tv|SUBMODE=off|PIPMODE=pipoff|RECMODE=recoff| OK The nomos system can evaluate sequences received from external systems and trigger further actions when

4.1. CommandServer Extension 127 nomos Documentation, Release 1.1.73 needed. In this manner the received data can be evaluated, transformed and transmitted to the actions to be carried out. We call this event-based reactive control. data volume \*\0x0D;VOLUME;; Reception of the current sound volume of the TV System with subsequent transmission to the AVR. With this, for example, the volume regulation of a connected AV Receiver can be accomplished with the remote controls of the TV System in the background.

4.1. CommandServer Extension 128 nomos Documentation, Release 1.1.73

4.1.2 Reserved (extended) server types [SERVERTYPE]

As previously described, there are embedded server classes or sum-checking calculations done by them that are already routinely deployed in nomos. These special server types can only be integrated by the nomos developers team. With them it is possible, for example, to make “Checksum” calculations or similar things. In general, such protocols are totally integrated by the nomos developers team and the corresponding deﬁnition tables, if present, are cleared for use. Naturally, the corresponding protocols can also be integrated into the possible procedures already described, except that no dynamic value can be delivered with, for example, protocols with attached Checksums. In a systems for multiple rooms, this would mean. for example, that a line would have to be entered in the deﬁnition table for each command. The following extended server types are integrated at the moment: RUS determines and sends the Checksum for the Russound Protokoll (HEX) ADNOTAM determines and sends the Checksum for the Adnotam Protocol (HEX) SPEAKERCRAFT determines and sends the Checksum for the Speakercraft Protokoll (HEX) For the application of one own Checksum rules there is the Option: SUM variable Checksum Option available. A precise explanation of the applciation is found in the previous chapter, CommandServer.

4.1. CommandServer Extension 129 nomos Documentation, Release 1.1.73

4.1.3 Employment of USB/RS232 converters

The nomos system supports the use of local USB/RS232 Adapters/Converters. With them one can dispense with external IP/RS232 converters as long as their installation allows this. The procedure for employing these adapters is explained and the required setup of the .csv file illustrated in the following. Application: SERVERIP;LOCAL Operating type for local devices SERVERPORT AUTO or {serial port{speed};{databits};{parity};{stopbit}{flow control} Explanation of the variables SERVERPORT with SERVERIP=LOCAL : The setting SERVERIP=LOCAL has to be made when using USB/RS232 adapters. AUTO Seeks out the first serial port in the system and uses this automatically. This utility actually makes sense only if one has installed only one USB/RS232 adapter. {serial port} the name of the interface in the format /dev/cu.xxxxxxx Use of the command GETSERIALPORTLIST from the Class gives information on the interfaces and device names used by the system. {speed} the speed with which the serial port is supposed to be driven; tested were 9600, 19200 and 115200 bps {databits} Number of databits (5-8) {parity} ‘n’ -> none ‘e’ -> even ‘o’ -> odd {Stopbits} Number of stopbits ( 1-2 ) {flow control} NONE , RTSCTS , DTRDSR , XONXOFF Example of setting for USB/RS232 Adapter:

SERVERIP;LOCALSERVERPORT;AUTO;115200;8;n;1;RTSCTSSERVERPROTOCOL;SERIAL Seeks out and opens the ﬁrst local USB/RS232 adapter to be found and sets up a COM interface with the parameters 115200,8,n,1 and activates RTSCTS ﬂow control. To obtain information on the sometimes rather cryptic device names, the command GETSERIALPORTLIST was integrated from the Class (system commands). Simply use the Scripting Client in order to retrieve the corresponding names.

4.1. CommandServer Extension 130 nomos Documentation, Release 1.1.73

All responding reports with the content: GETSERIALPORTLIST=/dev/cu.PL2303-0000201A| are corresponding USB/RS232 device drivers. In the case cited, the correct entry item would be in the .csv file: SERVERPORT;/dev/cu.PL2303-0000201A;115200;8;n;1;RTSCTS Appropriate for use when a device is supposed to be contacted by its direct address and when more than one USB/RS232 device is being used in the system. The first designation appearing in the list that was returned corresponds to the Auto Funktion in the .csv It is sensible when setting up a system to connect the converter now and then and in the meantime repeatedly to call up the above mentioned command in order to achieve the correct assignments and the corresponding port names. The port designation is based on the USB port into which the converter is inserted. That,. of course, can also be done with an external USB Hub. We have successfully tested adapters with the Profilic PL- 2303 Chip Set and therefore recommend their use exclusively. You will find the corresponding Apple OSX driver download for the Prolific PL2303 (this chip set is used by many different manufacturers) at the following address. http://sourceforge.net/projects/osx-pl2303/ The driver is also found in the provided CD in the index \Tools und Treiber\Profilic . Please be advised that the employment of the driver is subject to the GNU General Public License (GPL).

4.1. CommandServer Extension 131 nomos Documentation, Release 1.1.73

4.2 GIRA Homserver KO-Gateway, KNXnet/IP Support

We describe in the following segment the possible interfaces for linking into EIB/KNX. We will be continually adapting and expanding these interfaces in step with the demands of the market.

4.2.1 KNX-IP BAOS 770 nomos supports BAOS (Bus Access and Object Server) protocol, enabling direct processing of as many as 256 KNX objects per nomos system. The purpose of that is to integrate simple KNX processes such as the triggering of lighting effects, simple switching of lights with button commands or mremote visualization. Actions on the nomos system (script callup or command sequences) can also be initiated with this. In order to make use of this interface, the Weinzierl KNX IP BAOS 770 Interface is a prerequisite. The configuration and the definition of the KNX datapoints is done in the BAOS Interface with ETS (EIB Tool Software). The procedures can be found in the manufacturer’s documentation. Once the appropriate interface is put in place, nomos can communicate with the device and exchange data. With the inclusion of the KNXnet/IP protocol for Routing and Tunneling, the BAOS-Object/Server concept need not be pursued further. The Weinzierl KNX-IP BAOS770 Interface can also be operated in KNXnet/IP Tunneling Modus. Structure of the table of definitions:

Type: csv ﬁle Location: .\{projectPath}\misc\ Name: baos.csv Length: 1000 lines/entries Event: BC, status Export: no License: yes

The baos.csv is composed of three sections: [CONFIG]; general configuration of the interface parameter [DATAPOINTS]; definition of datapoints, which are to be transmitted together on the BC port (optional) [ACTIONS]; definition of datapoints, which are to initiate a direct action (script callup) Structure: • [CONFIG]; Section BAOSIP;{IP}/OFF/AUTO;{IP} IP of KNXBAOS (firm); OFF, BAOS function turned off; AUTO, IP of BAOS is automatically sought in the relevant network area • [DATAPOINTS]; Section (optional, needed for reception or script callup):

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 132 nomos Documentation, Release 1.1.73

{Number};{Name};{Typ} structure of the deﬁnition of a digital Join Explanation:

{Number} BAOS object number/datapoint {Name} Freely deﬁnable name of object written in words {HEX/DEC/ASCII} Type/mode of presentation of the object • [ACTIONS]; Section

{Number};{Value}/{#};{Action};{Type}; Explanation:

{Number} BAOS object number/datapoint {Value}/{#} Value when action is to be carried out; # = all values {Action} nomos sequence or script, which is to be executed, when the condition {Value} is true. If # is used as a wild card, value can be transferred by means of \# to the script or nomos sequence {Type} Type/mode of representation of the object HEX(default)/DEZ/ASCII Examples for Definitions [DATAPOINTS] Section: 9;bell;HEX generates the broadcast output: bell=’VALUE’ Examples for Definitions [ACTIONS] Section: 9;0A;script.myh;HEX Executes Script script.myh when Datapoint 9 has Value of 10 9;10;script.myh;DEC just as in previous 9;ON;script.myh;ASCII Executes Script script.myh when Datapoint 9 of ASCII sequence corresponds to “ON“ 9;#;script.myh;DEC Executes Script script.myh when Datapoint 9 changes value and transfers value [ARG] as decimal to the Script. 9;#;script.myh;HEX Executes Script script.myh when Datapoint 9 changes value and transfers the value [ARG] as hexadecimal to the script 9;#;script.myh;ASCII Executes Script script.myh when Datapoint 9 changes value and transfers the ASCII sequence as [ARG] to the Script As soon as the datapoints are defined, Daemon sets up a firm, sustained connection to the BAOS and immediately emits through the broadcast port the received value changes for the datapoints listed in .csv. An action can then be triggered in the Event server by means of its corresponding definition. Important tips: In general, reference to the datapoints is always made by using their object numbers. In other words, engagement is not made by using the corresponding EIB/KNX group address but by the object with which the address is associated. Direct command sequences or chains can also be used instead of calling up a Script file. Example: 9;1;;DEC

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 133 nomos Documentation, Release 1.1.73

A BAOS command class exists with the following commands:

Command Argument Description GETINFO provides general information on the BAOS provides installation settings of selected data- GETDESCRIPTION= {Datapoint number} points provides installation settings of selected data- GETDESCRIPTIONSTRING= {Datapoint number} points provides current value of a datapoint, including GETVALUE= {Datapoint number} status ﬂag in HEX format {Datapoint No.}, sets value of a selected datapoint in HEX, deci- SETVALUE= {HEX/DEC/ASCII} mal or as ASCII {Datapoint No.}, SENDVALUE= sends value to KNX bus {HEX/DEC/ASCII} {Datapoint No.}, SETANDSENDVALUE= combination of SETVALUE and SENDVALUE {HEX/DEC/ASCII} {Datapoint No.}, READVALUE= reads value from KNX bus {HEX/DEC/ASCII} CLEARTRANSMISSION- {Datapoint No.}, cancels connection status STATE= {HEX/DEC/ASCII} GETPARAMETERBYTE= Parameter No. provides byte of the selected parameter

Examples: Sets BAOS Object 4 to Value 1 Queries parameter of BAOS interface. Answer comes through BC port. Important tips: When ASCII is designated as type, the string is enlarged to 14 Bytes or cut off. If no argument is designated, a decimal value is assumed. With the „HEX“ type, the preﬁx „0x“ is not necessary.

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 134 nomos Documentation, Release 1.1.73

4.2.2 GIRA Homeserver KO-Gateway Support

The nomos system supports bi-directional access to the GIRA Homserver KO-Gateway. This makes possible a simple transfer of data – from the exchange of information to the gaining of access to EIB/KNX – that can be accomplished directly through a gateway. It is then no longer necessary for communication between nomos and the GIRA Homeserver to take place through UDP/TCP communication. Important tips: Please take care that the datapoints you you wish to evaluate or engage in GIRA Homeserver have been cleared for communication through the KO Gateway. Structure of the deﬁnitions table:

Type: csv ﬁle Location: .\{projectPath}\misc\ Name: hs.csv Length: 100,000 lines/entries Event: BC, Status Export: no License: yes

The hs.csv is composed of two sections: [CONFIG]; general configuration of the interface parameter [DATAPOINTS]; Definition of datapoints, which are supposed to be received and evaluated with GIRA Homeserver KO Gateway. Structure: Place in the miscellaneous folder a hs.csv file with the following content: • [CONFIG];Section ACTIVE;YES; Activates the KO Gateway Support „YES“ (default) / NO DEBUG;YES Extended protocol active “YES”/”NO” (default) HSIP;{IP Address} IP address of the GIRA Homeserver HSPORT;{KO Port number} Port of the GIRA KO-Gateway HSKEY;{password to be fixed in HS} Passwort/key of the KO Gateway ADDRTYPE;{Addresstype} determines how the address output is to be done in broadcast. Possible values „2STEP“ or „3STEP“. Empty or undefined = Decimal output. • [DATAPOINTS]; Section Section Optional / additional (needed for reception or Script callup)

{KO in GIRA Homeserver};{Datapoint-Name};{Condition};{mmh-Sequence} Explanation:

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 135 nomos Documentation, Release 1.1.73

{KO in GIRA Homeserver} Address of the communication object {Datapoint-Name} may be empty and is freely definable {Condition} can (corresponding to BAOS) have the following states: {Match-String} of the value sent by HS must agree with {Match-String} {#} all values start Script or the Sequence; if {condition} is empty, ’#’ is assumed. {mmh-Sequence} The command sequence to be carried out or the Script, when condition is met. Can contain wild card ‘\#’ for the value; with Scripts, the received value is sent as Argument. Important tips: Please take care that the KO Gateway values, which do not describe any ASCII text, convey floating-point values. Thus a binary „1“ or „0“ is rendered as „1.0“ or „0.0“ . The field {condition} must be defined accordingly.

Examples or the Deﬁnitions [DATAPOINTS] Section: 8/1/4;iTunes Next;1.0; Upon receiving the Address 8/1/4 with the value „1“, iTunes carries out the internal command „NEXT“ and PLAY. The report „iTunes Next=1.0“ is generated at the status port 8/1/7;TV ON;1.0; Upon receiving the Address 8/1/7 with the value „1“ , the Script „StartTV.myh“ is executed. The report „TV ON=1.0“ is generated at the status port. 5/1/0;Playlist;#; or, same value 5/1/0;Playlist;#; Upon receipt of the Address 5/1/0 (EIS15 ASCII Deﬁnition) with the assumed value „Music“, the Script „Play(Playlist).myh“ is executed and the incoming text sent as Argument. The report „Playlist=Musik“ is generated at the status port.

A class HS of commands exists with the following commands:

Command Argument Description SETVALUE# {Address},{Value} sets absolute {Value} in {Address}. SETVALUEREL# {Address},{Value} sets relative {Value} in {Address} . STEPUP# {Address} raises value in {Address}. STEPDOWN# {Address} lowers value in {Address}.

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 136 nomos Documentation, Release 1.1.73

Command Argument Description LISTUP# {Address} raises value in {Address}. LISTDOWN# {Address} lowers value in {Address}.

In lieu of {Address} the datapoint name registered in the .csv can also be used with all commands. When HomeServer responds to the command within 3 seconds, the value received is emitted as return value. In addition, values received from HS are sent through the Broadcast Port:

<{Address or Name, if deﬁned}={Value}><.....> Examples: Sets the address 4/1/1 to the value 1 Sets the value of the internal address according to the previous ﬁled list as the next value.

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 137 nomos Documentation, Release 1.1.73

4.2.3 KNXnet/IP (Routing und Tunneling)

KNXnet IP Routing-Support KNXnet IP Tunneling Support KNXnet IP TUNNELING_BRIDGE Support

The nomos system also supports the KNXnet/IP protocol. This tie-in currently offers the best interface with KNX/EIB because it imposes practically no restriction on the number of datapoints and no additional parameters must be set up within the ETS, as would be necessary, for example, with the BAOS Object Server. Both types of protocol, namely KNXnet/IP Routing and KNXnet/IP Tunneling, are supported. It is also possible to set up a „TUNNELING_BRIDGE“. Further explanation of this mode now follows. The datapoint definitions are laid out in a separate file (knx.esf) in the misc folder. This file is subordi- nated to the OPC Export Format of the ETS and can be exported directly from ETS. All types of datapoints are supported. This also applies to the names defined therein for the Broadcast output and used in the Logging Monitor. Thus type-conversion and scaling occur automatically and require no further attention. An individual name for the .esf file can also be assigned. This can be adjusted in the CONFIG section of knx.csv. A log entry occurs for unknown types of data in the .esf file and the corresponding definition is disregarded. Datapoints which are not entered in the .esf file are ignored. The following types of datapoints are currently supported:

EIS 1 ‘Switching’ (1 Bit) EIS 2 ‘Dimming - position’ (1 Bit) EIS 2 ‘Dimming - control’ (4 Bit) EIS 2 ‘Dimming - value’ (8 Bit) EIS 3 ‘Time’ (3 Byte) EIS 4 ‘Date’ (3 Byte) EIS 5 ‘Value’ (2 Byte) EIS 6 ‘Scaling - percent’ (8 Bit) EIS 6 ‘Scaling - degree’ (8 Bit) EIS 7 ‘Drive control’ (1 Bit) EIS 8 ‘Priority - position’ (1 Bit) EIS 8 ‘Priority - control’ (2 Bit) EIS 9 ‘Float value’ (4 Byte) EIS 10 ‘16Bit Counter’ (2 Byte) EIS 11 ‘32Bit Counter’ (4 Byte) EIS 12 ‘Access’ (4 Byte) EIS 13 ‘EIB-ASCII-Char’ (8 Bit) EIS 14 ‘8Bit Counter’ (8 Bit) EIS 15 ‘Character String’ (14 Byte)

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 138 nomos Documentation, Release 1.1.73

Since the OPC export interface is error-ridden ( 2-Byte ﬂoat-values such as temperatures are, for example, rendered as „uncertain“ = undeﬁned), we have made an adjustment. In this way, all 2-Byte uncertain datapoints are automatically interpreted as „EIS5’Value’(2-Byte)“ .

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 139 nomos Documentation, Release 1.1.73

KNXnet/IP Routing-Support

General: A KNX/IP routing-capable IP router will be sought automatically at the start and displayed in the corresponding log. nomos reads the multicast address of the IP router and enters the corresponding group. Advantage of the routing variants: Any desired number of nomos systems can operate simultaneously in connection with the KNXnet/IP device. The configuration file is named knx.csv and is stored in the misc folder. The addresses contained in the knx.csv are converted, the corresponding Actions executed and routed through the broadcast port. Structure of the definition table:

Type: csv ﬁle Location: .\{projectPath}\misc\ Name: knx.csv Length: 10,000 lines/entries Event: BC, status Export: no License: yes

The knx.csv is composed of 3 sections: [CONFIG]; general configuration of the interface parameter [DATAPOINTS]; Definition of datapoints which are to be received and evaluated through the KNXnet/IP. [TABLE={NAME}]; Scan definition tables, group poles Structure: • [CONFIG];Section ACTIVE;YES; Switches the KNXnet/IP support „YES“ = on, „NO“ = off DEBUG;YES Switch for „YES“ = extended log output (bus monitor) „NO“ = standard log output ESF;{ESF File}; Name of the .esf file in the folder misc (knx.esf = default) PHYSADDR;{Phys.Address}; Local physical address of the sender, the mmh to be used in transmitting. ADDRTYPE;{Addresstype} „2STEP“ = two-step description, „3STEP“ = three-step description (default) DPTNAMES;YES; Switches the names of the datapoints in the broadcast „YES“ = on (default), „NO“ = off

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 140 nomos Documentation, Release 1.1.73

MATCHLOCAL;YES; Determines whether actions defined in the DATAPOINTS can also be executed when the Daemon itself writes on the datapoints. „YES“ = on, „NO“ = off (default) INITSCAN;YES; scans the defined tables upon starting the engine „YES/ALL“ = on, „NO“ = off (default) SENDRATE;{Telegr/s}; Limits the number of „telegram“ transmissions per second written in the bus. The buffer is variable and surge resilient. „17“ (default). The value set here also applies to the spacing intervals of the query telegram initiated with SCAN=. CONNECTIONTYPE;{Protokolltype}; „ROUTING“ (default: ROUTING) or „TUNNELING“ or “TUNNELING_BRIDGE“ Specific settings for the operating mode „ROUTING“:

CONNECTIONTYPE;ROUTING; Needed with CONNECTIONTYPE;ROUTING is this additional switch: MULTICAST_IP;{Multicast ADR}; Multicast IP of the device’s standard: {224.0.23.12} or „AUTO“ for automatic searching (default: AUTO) • [DATAPOINTS];Section {KNX/EIB group address};{condition};{mmh sequence}; KNX events are evaluated directly in this ﬁeld, with appropriate actions initiated. Explanation:

{KNX/EIB Group address} Group address in corresponding ADDRTYPE setting {Condition} can have (corresponding to BAOS) the following conditions: {Match-String} of the value transmitted by KNX/IP must agree with {Match-String}. {#} all values start Script or the Sequence; if {condition} is empty, ’#’ is assumed. {mmh-Sequence} Command sequence or script name carried out if condition is met. Can contain wild card for the value ‘\#’ ; received value with script is passed along as argument

• [TABLE={NAME}];Section

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 141 nomos Documentation, Release 1.1.73

{Name} {NAME} deﬁnes a corresponding group. Any number of [TABLE={name}] sections can be set up. Their names will be required when using the SCAN commands, as explained in more detail later. {KNX/EIB Group address}; Group addresses to be scanned. Only one group address per line may be entered.

Examples of the definitions [DATAPOINTS] section: 8/1/4;1; For reception of the address 8/1/4 with the value „1“ , iTunes executes the internal commands „NEXT“ and PLAY. For each address multiple Actions can be defined, if separate Match conditions are assigned. Only the first Action found will be executed for a specific address with more than one identical Match condition. 15/7/10;1; oder 15/7/10;0; Executes on command only upon reception of logic „1“ of the address 15/7/10. Reception of a logic „0“ will execute only the command . 8/1/7;#;; Writes the received value in the system volume.

5/2/8;DOWN,100;;5/2/8;UP,100;; Receives and evaluates a 4-Bit dimmer telegram (EIS2). Recommended here is to have the corresponding KNX telegram sent cyclically (Note the setting on the corresponding sensor), since the corresponding command {mmh sequence} to be executed is triggered only upon receipt of each telegram. Examples for the scan support:

[TABLE=livingroom]; 1/8/4 1/8/5 1/8/7 1/4/3

[TABLE=bedroom]; 1/4/3 1/3/5 1/2/7

Deﬁnies two scan tables which can be called up with the SCAN commands. The SCAN can be done directly or run in the background. Please note that a SCAN can only work when the

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 142 nomos Documentation, Release 1.1.73

corresponding „l“ -ﬂag of the associated KNX communication object is set. This ﬂag should be set only once for each address on a communication object. The difference between the two SCAN methods lies in the time differential of the Read prompts. Quick queries can be generated with SCAN=. Note, however, that not too many telegrams with this speed should be requested. Intended for uninterrupted call-up of numerous telegrams, e.g. for an initial Scan, is the BACKGROUNDSCAN=. The telegram queries are executed sequentially after receiving answers. A maximum pause of 1 second precedes each answer. If no answer is received by this time, a report message ERR_NO_RESPONSE is generated. The answers to scans also appear in the broadcast (BC):

bc: <15/2/181-Geli.DimBelLlp.on/offStatus=0> bc: <15/5/28-SET_TEMP_Servercabinet=27.00> bc: <15/2/21- mike.DimBelLlp.on/offStatus=0>

There is a class of KNX commands containing the following:

Examples:

Triggers a query of group addresses, e.g. of those defined under [TABLE=Bedroom] Several tables can be queried simultaneously. Triggers a background scan of the table Bedroom. A background scan is quickly carried out with around three telegrams. Assigns the value of the group address 1/2/3 as 1 Setting the value of the group address 0/0/1 to the system’s current time. The fixed system variable [TIME] is formatted in the exact form for use in the KNX system. The same applies to the application of the firm system variable [DATE]. Polling values of the group address 1/2/33

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 143 nomos Documentation, Release 1.1.73

KNXnet/IP Tunneling Support

The same procedures described for the Routing Protocol also apply to Tunneling Support. Only the following switch in the CONFIG section of the knx.csv has to be made compatible or changed. The operating mode TUNNELING allows for only one active connection to the KNXnet/IP device. This may be a disadvantage, especially with large installations. In order to circumvent this „disadvantage“, we offer you the option of the „TUNNELING_BRIDGE“ with the operating mode. Speciﬁc installation for the operating mode „TUNNELING“:

CONNECTIONTYPE;TUNNELING For CONNECTIONTYPE;TUNNELING , the following additional switch is needed: DEVICE_IP;{Gateway IP} sets the IP of the KNX Tunneling device; possible values: {IP of the device} or „AUTO“ for automatic searching (default: AUTO)

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 144 nomos Documentation, Release 1.1.73

KNXnet/IP TUNNELING_BRIDGE Support

The KNXnet/IP Tunneling_Bridge Support serves to enable access to the KNX universe for several nomos systems through just one established tunneling connection. In the operating mode „TUNNELING_BRIDGE“ the nomos system works like a virtual KNX/IP Router, which secures the KNX connection through one tunneling connection. This modality can also be used, for example, for coupling equipment arrays. Procedure: Assuming at least two nomos systems with activated KNXnet/IP installation and one KNXnet/IP tunneling device, the following installation settings must be made: A nomos system must operate in the network as „Tunneling Master“. This secures the tunneling connection for the KNXnet/IP device. This nomos system simultaneously provides a Multicast address for the Routing Support. Through this Multicast address, additional systems can now communicate with the „Tunneling Master“. The additional nomos systems then work in the operating mode „Routing“. Please make sure that the Multicast address or the Multicast sector deﬁned by it is available only to the nomos systems. Should another Routing-capable KNXnet/IP device remain accessible anywhere within the whole structure, this can lead to disruption of communication. One must also make sure that no „AUTO“ function has been activated in the installations.

Conﬁguration „Tunneling Server“ (1st nomos system) knx.csv - The following installation settings deﬁne the KNXnet/IP Interface of the nomos system as Multicast-Gateway with tunneling access.

[CONFIG]; ACTIVE;YES; DEBUG;YES; ESF;knx.esf; PHYSADDR;0.0.254;

**** Installation for TUNNELING_BRIDGE ****

CONNECTIONTYPE;TUNNELING_BRIDGE Switch for operating mode DEVICE_IP;AUTO „AUTO“ seeks the KNXnet/IP device, but the installation of a ﬁxed IP address is preferable. MULTICAST_IP;224.0.23.15 initiates Multicast address segment for Routing service.

Conﬁguration „Routing“ (2nd through nth nomos systems) knx.csv – following installation settings as example.

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 145 nomos Documentation, Release 1.1.73

[CONFIG]; ACTIVE;YES; DEBUG;YES; ESF;knx.esf; PHYSADDR;0.0.253;

**** Installation for ROUTING ****

CONNECTIONTYPE;ROUTING Switch for operating mode MULTICAST_IP;224.0.23.15 Multicast address segment for which Routing Service has been provided. All devices in the net, which support the Routing protocol, can now establish their Gateway connections to the „Tunneling Master“ through this „MULTICAST_IP“ 224.0.23.15 and can simultaneously gain access to the KNX bus. Please check the logging output of each of the nomos systems after executing a “new start.” The log shows the connection status of each.

4.2. GIRA Homserver KO-Gateway, KNXnet/IP Support 146 nomos Documentation, Release 1.1.73

4.3 Event Server

Eventservers enable protocol (response) sequences of external systems to be integrated into the nomos protocol structure and their systemic conditions to be monitored. External protocols can also be processed here directly and, when necessary, direct actions (nomos script or command strings) can be executed. This becomes necessary, for example, when a response should be made to the “feedback” of some device (e.g. turning on the AppleTV with the Apple Remote remote-control gadget or the Remote APP). It is typically possible then to achieve the following functionality...... IF APPLE TV = ON, then send SCRIPT TV ON and SWITCH TV INPUT TO HDMI1 Event definitions are set forth in the subfolder .\{projectPath}\events\ . The file format is also *.csv. The [file name].csv may be chosen at will. Please note that a maximum of 25 event definition tables (files) are possible. Moreover, a separate license is required for the general processing of event definitions. Also possible are several definiton files per port. With a valid Event, the line number of the matches and the file name of the .csv are reported in the logging. Eventservers open the connection directly upon the start of the nomos system and hold this open. Eventservers can, among other things, also be employed on nomos’ own communication ports (Status Broad- cast, Log, Control Port).

Structure of the deﬁnition table:

Type: csv ﬁle Location: .\{projectPath}\events\ Name: {EventClass}.csv Length: 1000 lines/entry items Event: - Export: - License: y

The {Event Class}.csv is composed of 2 sections: [CONFIG]; general conﬁguration of the Interface Parameter [TRIGGERS]; Event Deﬁnitions Structure: An‘‘{Event Class}.csv‘‘ with the following content is docked in the events folder: • [CONFIG];Section ACTIVE;YES activates/deactivates the Webserver „YES“ (Default)= active, „NO“ = not active

4.3. Event Server 147 nomos Documentation, Release 1.1.73

DEBUG;YES Extended LOG output „YES“ = active, „NO“ (Default) = not active TRIGGERIP;{TYPE}; Designation of the source address of the remote system. This can have the following settings: {IP Address} remote IP Address (trigger) INTERNAL for monitoring the system’s own ports ANY for connection of any desired IP address TRIGGERPROTOCOL;{TYPE}; designation for the protocol that is supposed to be received: TCP waits for TCP connections UDP waits for UDP connections TRIGGERPORT;{PORT}; designation of the port address or communication channel. The settings depend upon the respective settings under TRIGGERIP; {PORT Address} local port for the designation of an IP address under TRIGGERIP For the use of the setting TRIGGERIP;INTERNAL the following parameters are relevant*: IN monitors the incoming packets of the Communications Port (1037) OUT monitor the outbound packets of the Communications Port (1037) LOG monitors output from LOG Port (1039) BROADCAST monitors the output of the Broadcast Status Port (1038) TRIGGERMODE;{Mode}; setting for the data type of the protocol: ASCII awaits incoming data in ASCII format HEX awaits incoming data in HEX format. MATCHING;{Mode}; setting for handling the parsing of the TRIGGERS. Possible parameters: NORMAL (Default) - this setting causes the processing of the incoming data packet to take place sequentially. The incoming string with a successful match is abbreviated accordingly (reduced behavior). Only the remainder of the incoming string is available to an additional trigger within the .csv ﬁle representing the matching condition. FULL makes possible a line by line parsing of the incoming string. The incoming string is therefore available in full length for each trigger entry. It can also be triggered with comparative conditions. Example of the setting for the internal Event Support (assuming that nomos Standard Port is being used):

4.3. Event Server 148 nomos Documentation, Release 1.1.73

TRIGGERIP; INTERNAL and TRIGGERPORT; OUT causes the TRIGGERS to be applied to the response sequences emitted from Port 1037 of nomos. TRIGGERIP; INTERNAL and TRIGGERPORT; IN causes the TRIGGERS to be applied to the command sequences written to Port 1037 by nomos. TRIGGERIP; INTERNAL and TRIGGERPORT; LOG causes the TRIGGERS to be applied to the answering sequences that nomos emits at Port 1039. TRIGGERIP; INTERNAL and TRIGGERPORT; BROADCAST causes the TRIGGERS to be used on the response sequences that nomos emits on Port 1038 or the Status Port. Only the broadcast output emitted from the local nomos Daemon is engaged by this. • [TRIGGERS];Section Section for the TRIGGER deﬁnitions that parse the incoming data. {Match-String};{Action or Scriptname};{Options};{Condition}‘

{Match-String} The matching condition with which the incoming data is tested. The value that is extracted by the parsing options ( see Chapter: Parsing Options (Match Conditions) is automatically transferred as „Argument“ to the Script that is called up. The match condition is not case-sensitive {Action or Scriptname} nomos Script or Command Sequence that is triggered with the successful Match. {Options} If ONCHANGE (optional) is used as Option, an action is only carried out when a change of value has occurred after the last Trigger. The setting is only sensible if a variable value is supposed to be evaluated. {Match-Condition} Optional comparators („>“,“<“,“=“) can be employed here. Such combinations as „<>“ (unequal) or „>=“ (smaller or equal) can be deﬁned. When Match Conditions are employed, both the Conditions and the successful Match must be fulﬁlled in order to execute an action. Examples for internal Eventservers: When making the rules or triggers for the various Eventservers, it is helpful to keep an eye on the LOG. Please open the corresponding LOG information with the help of the Scripting Client or by using Netcat. Copy from the LOG the portion you wish to process and process the input accordingly, inserting the parsing options that are needed. Text segments to be ignored should be replaced with a \% , while those whose values are to be received and processed should be replaced with \*. The employment of further Parser Options can be found in the corresponding chapter. Evaluation of the current system sound volume from the Broadcast Status Port

TRIGGERIP;INTERNAL and TRIGGERPORT; BROADCAST \%|VOL=\*|;;ONCHANGE;>=70 matches the system sound volume emitted at the Status Port. If the value is greater or the same as 70 , the volume is reset to „69“‘‘with an appropriate command. The comparison take place only with a value change (‘‘ONCHANGE). Depending upon the settings, the parser seeks out a character string that begins with and generates a character string |VOL= after some desired number of charac-

4.3. Event Server 149 nomos Documentation, Release 1.1.73

ters. All the subsequent characters until the next | is reached are now collected. The corresponding Match is „81“. The value 81 conforms to the Match Condition >=70 , resulting in the execution of the command . Evaluation of a current Player Status from the Broadcast Status Port with dynamic formation of the script name

TRIGGERIP;INTERNAL and TRIGGERPORT; BROADCAST

GETPLAYERSTATE=\*|;;ONCHANGE; Matches the character string after GETPLAYERSTATE=. The characters, as previously explained, are collected until the |‘‘is reached. In accordance with the incoming data, the match is ‘‘„PLAYING“. These data are now transferred to the Action with the Parameter \# . In this case, it causes the Script Name to be augmented accordingly. Thus SetAMP_\#.myh becomes SetAMP_PLAYING.myh. Various scripts can be carried out with this status steering. Assignment of output of speech recognition to corresponding functions

TRIGGERIP;INTERNAL and :txt-font-bold‘TRIGGERPORT;‘ BROADCAST \%USERSAID=\%licht ein\%|;; receives packets from each DEVICE (name disregarded) and anticipates a „oght on“ as ﬁxed value. The action is carried out if the condition is met. Monitoring of an incoming command sequence with subsequent action

TRIGGERIP;INTERNAL and TRIGGERPORT; IN

\%\%;; matches an incoming command sequence to the commands and of the class. If this condition is met, the window is closed after 3 seconds. Monitoring of a response sequence with subsequent action

TRIGGERIP;INTERNAL and TRIGGERPORT; OUT \%FSON=|OK;; matches the answer to an executed ..-command and carries out the script MuteAll.myh if match is successful. Example of external Eventserver: HTTP Eventserver, which executes an action upon receiving a corresponding URL. The following Eventserver makes possible the transmission of nomos protocol sequences as URL. Please deﬁne for this an Eventserver with the following settings:

4.3. Event Server 150 nomos Documentation, Release 1.1.73

Please be aware that Port 80 is already earmarked for possible internal Webservers.

[CONFIG]; ACTIVE;YES TRIGGERIP;ANY; TRIGGERPORT;2000; TRIGGERPROTOCOL;TCP; TRIGGERMODE;ASCII;

[TRIGGERS]; GET /\* HTTP;<\#> TRIGGERIP can, of course, also be assigned a ﬁxed IP address. In this case, the Eventserver responds exclusively to this Client address. Only queries from any of the possible clients are served with the Parameter ANY

Now please open a browser and send the following URL: http://192.168.1.213:2000/HELLO The IP address must, of course, be compatible with the correspondingly targeted system, or one may use localhost (127.0.0.1) for the local access. The following can now be observed in the protocol:

The TRIGGER rule GET / \* HTTP now ﬁlters out the appropriate command from the URL Header and transmits the value „hello“ to an action to be carried out. The command sequence is now augmented to and executed.

4.3. Event Server 151 nomos Documentation, Release 1.1.73

4.4 Airport Support (Airfoil)

The nomos system supports the control of external loudspeakers such as Apple Airport Express. The use of this function calls for the employment of Airfoil (Mac only) software. The software can be obtained from the following URL: http://rogueamoeba.com/airfoil/mac/. You will ﬁnd the installation instructions on the Homepage of the manufacturer. Please note that the applications with which sound is to be transmitted according to the Airfoil settings must be registered (as appearing in the PullDown Menu of Airfoil). The set of Airport commands is found in the class, with the following additional commands:

Command Argument Description lists all available Airports with names (“Com- GETSPEAKERLIST puter” is the local sound of Apple Computers) gives the current application or the active in- GETSPEAKERSOURCE take, from which sound is presently being streamed selects the application, from which sound is to SETSPEAKERSOURCE# {Appname} be streamed SETSPEAKERSOURCEDE- selects the audio intake from which sound is to {intake} VICE# be streamed ICE# GETAUDIODEVICELIST lists all available audio inputs reports the current sound volume of the selected GETSPEAKERVOL# {Airport-Name} Airport sets the absolute volume of the selected Airport; SETSPEAKERVOL# {Airport-Name,} {0...100} if the name is omitted, the volume is set for all Airports (including “Computer”) elevates the volume by a given value; name is SPEAKERVOLUP# {Airport-Name,} {0...100} also optional here lowers the volume, is otherwise like SPEAKERVOLDN# {Airport-Name,} {0...100} SPEAKERVOLUP ENABLESPEAKER# {Airport-Name} switches the chosen Airport on DISABLESPEAKER# {Airport-Name} switches the chosen Airport off ENABLEALLSPEAKERS switches all Airports on DISABLEALLSPEAKERS switches all Airports off delivers the status of the selected Airports: GETSPEAKERSTATE# {Airport-Name} ENABLED / DISABLED / NOT_AVAILABLE

We expressly advise that no multiroom applications can be accomplished with this solution. The Airport controls serve only for a simple chain of 3 or 4 additional audio zones at most. Also to be noted is that the stream of reception is somewhat delayed in time. It is not possible, for example, to synchronize audio stream. This delay means that audio replay from, for example, TV broadcasts or other applications with audio/video transmission is not synchronized with the visibly spoken word and is therefore not recommended.

4.4. Airport Support (Airfoil) 152 nomos Documentation, Release 1.1.73

4.5 eyeTV - Streaming Support

If the system has a TV Tuner, it is possible (Mac only) to stream the TV channel playing on eyeTV into the network. The stream can be received, for example, with free VLC software. The required eyeTV plug-in is installed automatically with the nomos Installation Routine. The control of the Streaming Servers takes place with the following commands in the Class STREAMER:

Command Argument Description starts the Streaming Engine and, if present, the ON EyeTV (minimized) stops the Streaming Engine, EyeTV keeps run- OFF ning selects the Streaming source; these commands function as analog to the SELECT command in {channelnumber} or {channel- CH# the Windows class. All subsequent, channel- name} speciﬁc commands are directed toward the last channel chosen with CH delivers a list with all currently available chan- GETCHLIST nels and their respective channel numbers. assigns a target to the source selected by CH and immediately begins UDP Streaming to the ADDTARGET# {IP:Port} given address. A particular Streaming ID is reported back. Please transmit the VLC to the client as URL udp://@:{Portnumber}. stops streaming the Stream given through {IP:Port} or {Streaming-ID} or IP:Port or ID‘. If only the ‘‘IP REMOVETARGET# {IP} is given, all streams directed at this IP are halted. REMOVEALLTARGETS stops all streams GETTARGETSFORIP# {IP} lists all streams directed to the IP {channelnumber} or {channel- lists all IP addresses to which the channel GETTARGETSFORCH# name} is being streamed GETALLTARGETS lists everything that is being streamed

Basics: The channel numbers of the various broadcasters are not ﬁxed and can change upon New Start of EyeTV or nomos. It is therefore sensible to select the broadcaster by its name. All broadcasters on a single transponder are always available. Therefore, 16 programs are simultaneously possible with 4 tuners, if one carefully chooses the broadcaster in EyeTV. Thus a USB Stick in the Dual Mode delivers 8 programs at the same time. Should streaming disruptions occur with more than 2 TV displays in EyeTV, this results from the heavy processing burden of EyeTV. In this case we recommend simply minimizing the necessary non-local TV displays in the Dock. Streaming to broadcast addresses is possible. The number of streams is limited only by the system hardware or the network. Additionally, TCP Streaming is possible without steering commands: The Port Number for this corresponds to the Channel Number+61000. If, for example, RTL is running on Channel 5, the VLC can retrieve this program with the URL tcp://{IP-Adresse}:61005. The number of TCP Streams is not limited

4.5. eyeTV - Streaming Support 153 nomos Documentation, Release 1.1.73 either. Should momentary (sound) disruptions occur during TCP streaming, please boost the cache capacity in the settings of the VLC to, e.g., 500ms. Examples: reports all currently available DVB streams:

UDP streaming of the program „Das Erste“ to IP 192.168.1.240, Port 45678:

answer: CH=1 | Das Erste | OK | ADDTARGET=567739290 | OK

4.5. eyeTV - Streaming Support 154 nomos Documentation, Release 1.1.73

4.6 Apple Remote Support iTunes and AppleTV control. At System Start there is an attempt to connect each deﬁned dynamic class in the remote.csv. When the application within iTunes or the Private-Clearance/Homesharing of AppleTV is activated, the nomos system recognizes this fully automatically. When this occurs, the rudimentary Re- mote Command set (except for the Button Commands, which always function only with AppleTV) are at your disposal. When the pairing is executed (see discussion below), an extended command set becomes available for control. The extended set of commands, however, is at hand solely for controlling a „remote“ iTunes. Always on hand for AppleTV, regardless of whether it is connected by Private-Clearance/Homesharing or through the Pairing Method, is only the rudimentary Remote Command Set. Since the nomos system, because of the behavior of the protocol, cannot recognize which system is the target system (ATV or an iTunes that is not paired), the invalid commands for the Homesharing Protocol are rejected or an Error Report is generated. The installation of the nomos system software on the target system is not necessary for the control of a „remote“ iTunes. The LOG reports which protocol has been activated for the device to be controlled: A connection to the device cannot be made

Extract from the LOG for a connected AppleTV (deﬁned as ATV) and activated Private-Clearance/ Home- sharing

Extract from the LOG for a connected iTunes (deﬁned as MBP) and activated Private- Clearance/Homesharing

LOG extract for a connected iTunes (deﬁned as MBP) after successful pairing. Now the complete set of commands is available here.

The expanded protocol also has a set of commands for controlling „remote speakers“ (Airstream), if these are recognized by the iTunes to be controlled remotely. The Airstream control here must not be confused with Airfoil Control. Structure of the deﬁnition table:

Type: csv ﬁle Location: .\{projectPath}\misc\ Name: remote.csv Length: 25 lines/entries Event: BC, status

4.6. Apple Remote Support 155 nomos Documentation, Release 1.1.73

Export: no License: yes

The remote.csv consists of 2 sections: [CONFIG]; general conﬁguration of the interface parameter [CONFIG]; List of devices to be controlled remotely. No more than 25 devices can be reported Structure: • [CONFIG];Section ACTIVE;YES; Switches Remote Modul „YES“ = on (default), „NO“ = off DEBUG;YES Switches for „YES“ = expanded Log output (Busmonitor) „NO“ = standard Log output (default) • [DEVICES];Section {devicename};{IP address}; Assignment of device IP address to the appropriate dynamic class for protocol support. Explanations:

{devicename} Name of the device to be controlled. The name given here describes the class in which the device can be contacted. {IP address} IP address of the AppleTV to be controlled or the Apple or Windows Computer with the installed iTunes software to be controlled. Beispiele für die Definitionen [DEVICE] Sektion: ATV;192.168.1.21 Defines a device with the name ATV to the IP Address 192.168.1.21. The device can now be controlled through the Class . MBP;192.168.1.20 Defines a device with the name MBP to IP Address 192.168.1.20. The device can now be controlled through the Class . It does not matter at all in this case whether the device to be controlled is an AppleTV or a „remote“ iTunes System. The nomos system recognizes the device and the probable protocol automatically. The class defined under {Gerätename} may not be present more than once in the system. The name also may not correspond to a class name that is already reserved. The device to be controlled must have either activated the PrivateClearance/Homesharing or be paired, or both. The Pairing: After you have registered the device or the target system of the „remote“ iTunes installation in the remote.csv, you can initiate the pairing. The iTunes application to be opened on the target system for pairing. Pairing basically must be done only once.

4.6. Apple Remote Support 156 nomos Documentation, Release 1.1.73

To initiate the pairing, the following command is available: starts the Remote Pairing An appropriate function for initiating the Remote Pairing is also available in the Scripting Client

When the Remote Pairing Mode is active, the nomos system becomes visible in iTunes or in AppleTV:

With AppleTV you ﬁnd this option in the Settings under Remote Control and therein correspondingly under iOS Remote Remote Control. After the selection you will be prompted to enter a 4-digit Code. This code can be chosen at will and has no further effect upon the pairing procedure. From this point on, the deﬁned classes with their commands are at hand. nomos system takes care of making the connection in the background (see Log). In the LOG appear typical reports:

4.6. Apple Remote Support 157 nomos Documentation, Release 1.1.73

Report that the Remote Pairing is active

Report that the Pairing has been carried out successfully.

Please do not forget to deactivate the Pairing Mode again. This is done either with the corresponding Button in the Scripting Client or with the direct command: Ends the Remote Pairing The Pairing Mode is also deactivated after the New Start of the Daemon. Following successful registration, the device can now be controlled. The status update of the remote device takes place automatically in broadcast whenever the Play Status or the current title of the corresponding device change.

The current cover can also be called up with the Mini-Webserver . http://{IP}:{Portnumber}/{Class}_current.jpg shows the cover of the running title of the class in use, as in the remote.csv An AppleTV can only be steered sensibly with the OSD because of its limited protocol. A protocol- supported title/album or Playlists selection is unfortunately not possible. There is a dynamic class of commands [Remote] with the following commands: Commands that await an Argument can also process lists.

4.6. Apple Remote Support 158 nomos Documentation, Release 1.1.73

Command Argument Description BUTTON_SELECT simulates a key stroke of the AppleRemote simulates a key stroke of the AppleRemote BUTTON_SELECTLONG (Context Menu) BUTTON_MENU simulates a key stroke of the AppleRemote Expanded set of commands, not for connection - extended commands - through Home Sharing ADDIDTOQUEUE# {ID} attaches the ID x to the Up-Next-Queue ADDTITLETOQUEUE# {Name} attaches Title x to the Up-Next-Queue ADDARTISTTOQUEUE# {Name} attaches Performer x to the Up-Next-Queue ADDALBUMTOQUEUE# {Name} attaches Album x to the Up-Next-Queue CLEARQUEUE erases Up-Next Queue DISABLEALLSPEAKERS turns off all audio output devices DISABLESPEAKER# {Speakername} turns {Speakername} off ENABLEALLSPEAKERS turns on all audio output devices ENABLESPEAKER# {Speakername} turns {Speakername} on GETALLALBUMS provides a list of all albums GETALLARTISTS provides a list of all performers GETALLIDSOFPLAYLIST# {Playlist} delivers all IDs in {Playlist} (max. 250) GETALLTITLESOFPLAY {Playlist} gives all titles in {Playliste} (max. 250) LIST# GETALLARTISTSOFPLAY gives all performers in {Playliste} (max. {Playlist} LIST# 250) GETALLALBUMSOFPLAY {Playlist} lists all albums in {Playliste} (max. 250) LIST# GETALLPLAYLISTS delivers a list of all the Playlists on hand GETIDALBUM# {ID} lists the album with the assigned {ID} GETIDARTIST# {ID} lists the performers on the speciﬁed {ID} GETIDTITLE# {ID} gives the title with the given {ID} furnishes a list of all recognized audio output GETSPEAKERLIST devices gives the status (ON or OFF) of GETSPEAKERSTATE# {Speakername} {Speakername} gives the volume of an Airtunes loudspeaker GETSPEAKERVOL# {Name} with reference to the Master Volume gives the current sound volume of the applica- GETVOL tion PLAYID# {ID} plays the title {ID} PLAYPLAYLIST# {Name} plays the Playlist {Name} SEARCHALBUM# {Album} lists all IDs, which belong to {Album} reports a list of the performers, who are in- SEARCHARTIST# {search string} cluded in the search string (Limit: 50) delivers a Track-ID list of the titles, which con- SEARCHTITLE# {search string} form to the search string (Limit: 50) sets the sound volume of an Airtunes loud- SETSPEAKERVOL# {Name}, {Value 0-100} speaker with reference to the Master Volume SETVOL# {0...100} sets the volume, 0 to 100%

There are corresponding SYS commands for this:

4.6. Apple Remote Support 159 nomos Documentation, Release 1.1.73

Examples for AppleTV: In the following example, an AppleTV with the Class was registered. If an AppleTV happens to be in Standby Mode, receipt of the command automatically awakens it. Please note that the AppleTV can only be controlled with the reduced Homesharing set of commands. A steering console is also on hand in the Scripting Client. With this option you can test the possibility of controlling in a simple manner.

Upon making this choice, a dialog window (display can vary) appears, allowing the control of all registereed devices through the Homesharing Protocol. The current status and the type of information is also displayed.

4.6. Apple Remote Support 160 nomos Documentation, Release 1.1.73

Simulates the key stroke of the OK Key of the Remote remote-control gadget. Simulates the key stroke of the Menu Key of the Remote remote-control gadget. Simulates the key stroke of the „Left“ Key of the Remote remote-control gadget. queries the current status of the device; is also automatically generated through Event.

Answer: GETALLPLAYLISTS{%l2,5}=music | items on loan | ﬁlms | TV | broadcasts | OK

4.6. Apple Remote Support 161 nomos Documentation, Release 1.1.73

initiates the query of the output of a Playlist from Index 2 with a length of 5 elements. Starts playing the music on Playlist Examples for iTunes loudspeakers: In the following example, a „remote“ iTunes with the Class and an AppleTV with the Class were registered.

initiates the query of possible „remote“ loudspeakers, resulting in the typical answer:

GETSPEAKERLIST=Computer|Apple TV|OK

Activates all registered „remote“ speakers, including output from the computer Sets sound volume of the Apple TV at 80%; volume here is always relative to the maximum value, which was prescribed with SETVOL (Master Volume). Some output device always has to be active because of the nature of the system. If all loudspeakers are turned off, iTunes automatically activates the local audio output.

4.6. Apple Remote Support 162 nomos Documentation, Release 1.1.73

4.7 Sonos Streaming Player Support

Controlling Sonos music players. For every class defined in the sonos.csv an attempt will be made at System Start to establish a connection. The configuration is similar to that which was previously described for remote.csv. Pairing, or something similar, is not necessary here. Since the Sonos Engine is based on UPnP, a UPnP license is required for the controls. Sonos works with a queue which (except for the radio station, which can be called up with a PLAYFAVORITE={station name} ) will now have to be filled. The PLAY* command does this automatically. The limitation of the GETALL* command to 100 entries on output can be circumvented with the list formatter {%lx,y}; nevertheless, in no case will output exceed 100 entries. Pay services (Spotify/Netstreams), such as Status Broadcast Output and Cover Support, are also supported. Structure of the definitions table:

Type: csv ﬁle Location: .\{projectPath}\misc\ Name: sonos.csv Length: 25 lines/entries Event: BC, status Export: - License: yes

The remote.csv is composed of 2 sections: [CONFIG]; general conﬁguration of the interface parameter [DEVICES]; List of the devices to be remotely controlled. A maximum of 25 devices can be reported Structure: • [CONFIG];Section ACTIVE;YES; Switches the Sonos Module „YES“ = on (default), „NO“ = off DEBUG;YES Switch for „YES“ = expands log output (Busmonitor) „NO“ = standard log output (default) • [DEVICES];Section {devicename};{IP address}; Assignment of the device’s IP address to the corresponding dynamic class for the protocol support. Explanation:

{devicename} Name of the device to be controlled. The name given here describes the Class {CLASS} , with which the device can be contacted. When the

4.7. Sonos Streaming Player Support 163 nomos Documentation, Release 1.1.73

Zone Name of the Player is entered as Class Name, there is no need to assign {IP-Adresse/Grupenname} (IP address/group name). {IP-address/groupname} IP address or group name of the Sonos device to be controlled The BC status output All status reports are transmitted by status broadcast without a speciﬁc query. The data can be evaluated and processed by means of EventServer. Output of Player Status for an Internet Radio Stream

Output of Player Status for a ﬁle playback

Output of the parameter for the sound volume and pitch setting

The actual cover of the current title can also be obtained if it is supplied through the MiniWebserver and can be retrieved with the following URL:

http://{SYSTEM IP}:{WEBSERVER PORT}/{SONOS_CLASS}_current.jpg There is a command class [SONOS] with the following commands:

Command Argument Description PLAY plays current title PAUSE interrupts current title STOP stops current title NEXT jumps to the next title PREV jumps back to the previous title

JUMPTOINDEX# {1...x} jumps to the x title in the queue GETVOL delivers the application’s current sound volume SETVOL# {0...100} sets the volume, 0 to 100% SETBALANCE# {-100...0...100} sets the balance (-100) left - (+100) right GETBALANCE delivers current balance MUTEON muting switched ON MUTEOFF muting switched OFF LOUDNESSON Volume ON LOUDNESSOFF volume OFF SETTREBLE# {-10...0...10} EQ sets the treble SETBASS# {-10...0...10} EQ sets the bass SETPTIME# {seconds} jumps to the given playing time

4.7. Sonos Streaming Player Support 164 nomos Documentation, Release 1.1.73

Command Argument Description GETPTIME delivers the actual playing time in seconds GETCTIME delivers the time played in seconds switches the Repeat Mode of the current playlist SETREPEAT# {ON/OFF,1/0,YES/NO} on or off switches the Random Mode of the current SETSHUFFLE# {ON/OFF,1/0,YES/NO} playlist on or off switches Cross-fade Mode of the current SETCROSSFADE# {ON/OFF,1/0,YES/NO} playlist on or off. GETALLPLAYLISTS delives a list of all playlists on hand erases the queue and immediately plays Playlist PLAYPLAYLIST# {Name} {Name} includes Album {Name} at the end of the ENQUEUEPLAYLIST# {Name} queue GETALLTITLESOFPLAY {Name} reports all titles on the Playlist {Name} LIST# GETALLARTISTSOFPLAY {Name} gives all performers on the Playlist {Name} LIST# GETALLALBUMSOFPLAY {Name} lists all albums on the Playlist {Name} LIST# GETALLALBUMS provides a list of all albums erases the queue and immediately plays Playlist PLAYALBUM# {Name} {Name} includes Album {Name} at the end of the ENQUEUEALBUM# {Name} queue GETALLTITLESOF ALBUM# {Name} gives all titles of the Album {Name} GETALLARTISTSOF AL- {Name} gives all performers in Album {Name} BUM# GETALLFAVORITES gives all favorites PLAYFAVORITE# {Name} plays the Favorite {Name} immediately GETALLTITLESOFQUEUE gives all titles in the queue GETALLARTISTSOFQUEUE gives all performers in the queue GETALLALBUMSOFQUEUE lists all the albums in the queue CLEARQUEUE deletes content of queue LEDON turns on the LED of the Sonos device LEDOFF turns off the LED of the Sonos device includes an additional Sonos device with the Class Name {Name} as a replay device (source ADDMEMBER# {Name} synchronizing), “x” has to be deﬁned in the sonos.csv. REMOVEMEMBER# {Name} removes the Sonos device with that class name streams the signal from the Line-In Port to the STARTLINEINSTREAM# {Name} device with the class Name “x”; “x” has to be deﬁned in the sonos.csv STOPLINEINSTREAM# {Name} stops the stream to Device “x” plays the signal locally from the Line-In Entry Port (“entry port” ? – there are a lot of ways to PLAYLINEIN translate Eingang: port, portal, entrance, entry, gate, gateway, etc.)

4.7. Sonos Streaming Player Support 165 nomos Documentation, Release 1.1.73

Command Argument Description -15 - (+)15 - attunes the sensitivity of the Line- SETLINEINLEVEL# {-15 - 15} In Port to the analoge source delivers the selected sensitivity of the Line-In GETLINEINLEVE Entry Port

Examples: <{SONOS_CLASS}> delivers a list of all playlists on hand <{SONOS_CLASS}> Starts playing the playlist with the name Sonos2 <{SONOS_CLASS} > Sets the sound volume of the Sonos device to 23% jumps to the 7th title on the current playlist or in the current album.

4.7. Sonos Streaming Player Support 166 nomos Documentation, Release 1.1.73

4.8 Z-Wave Support

Z-Wave is a wireless communication standard developed by the company Sigma Designs and the Z-Wave Alliance for Home Automation. The hardware-like protocol levels since 2012 are deﬁned 1 by the ITU-T as Standard G.9959 Speciﬁcations: • Transmission speed: 9,600 bit/s or 40 Kbit/s • Modulation: 2-FSK • Range: As far as 200 meters in open space, considerably less in buildings, depending upon the type of building material used; usually around 30 m. • Frequency band: Z-Wave uses the ISM band in the range of 900 MHz; in the U.S. this is 908.42 MHz; in Europe 868.42 MHz. Z-Wave is available at the moment only for the nomos Box and the nomos Pi.

Z-Wave components must be reported to the nomos system. To do this, the Z-Wave interface has to be set to the Include Mode. The Include Mode is active for around 30 seconds. The relevant Z-Wave device has to be picked up within that time. This occurs as a rule by tapping the Mode or Program key three times at short intervals (1s). The exact procedure can be found in the description of the devices being used. A successful reporting of the Z-Wave components to the nomos system is possible only if the components are also present in the Z-Wave databank. There is also the possibility to create one’s own databank ﬁles and to introduce them manually into the databank of the nomos system. In this case, the appropriate commands are available. If you happen to have a component that is not recognized, we nevertheless recommand that you contact nomos System Support. The Z-Wave databank of the nomos systems is based on the data of Pepper One GmbH (http://www.pepper1.net), the certiﬁcation arm of the Z-Wave Alliance. The nomos system has direct access to the updates of the Pepper One Datenbank. It is therefore recommended that any updating of the databank be accomplished before the inclusion of new devices. An appropriate possibility for this purpose is available in the Wizard.

1 Source: http://de.wikipedia.org/wiki/Z-Wave

4.8. Z-Wave Support 167 nomos Documentation, Release 1.1.73

The reporting of Z-Wave components is described in more detail below. The Z-Wave AddOn also requires a configuration file. This file can be acquired automatically from the nomos system according to the procedure during installation. Structure of the Definitions Table:

Type csv ﬁle Location: .\{projectPath}\misc\ Name: zwave.csv Length: 1,000 lines/entries Event: - Export: - License: -

The zwave.csv is composed of 2 sections: [CONFIG]; General configuration of the interface parameter [nodes]; Definition or name assignment of the Z-Wave nodes (devices) Structure: zwave.csv with the following content (automatically generated) is in the misc folder: • [CONFIG];Section ACTIVE;YES Activates/deactivates the Webserver „YES“ (Default)= active, „NO“ = not active DEBUG;YES Extended LOG output „YES“ = active, „NO“ (Default) = not active PORT;{Portnumber} "AUTO" or serial port to which the Z-wave controller is connected (/dev/ttyS1, /dev/ttyUSB0 etc... ), optional, default: AUTO • [NODES];Section Assignment of plain-text name to the Node ID. The Node ID is con- ferred by the system once, when the device is picked up. {NodeIndex};{Nodename} Examples of the definitions [NODE] Section: 2;FEKO_DOOR_LR; Assigns to the NODE_ID 2 the name „FEKO_DOOR_LR“ 3;BWM_LR; Assigns to the NODE_ID 3 the name „BWM_LR“ The Node ID is automatically generated when the system picks up the node. When a device is successfully included, a Standard Entry (x;NODE_x) is generated in the zwave.csv. The

4.8. Z-Wave Support 168 nomos Documentation, Release 1.1.73

{NodeIndex} is ﬁxed and may not be changed. The {Nodename} may be changed at will. Please do not remove any entries from the zwave.csv. When the device is removed, please use the EXCLUDE command. Including and removing a Z-WAVE device/node New Z-Wave devices have to be read into the nomos system. To start this learning process, the command is available. The process of reading in can be followed in the Log. When is executed, the device to be read in has to be placed in the inclusion mode. This procedure is initiated as a rule by brieﬂy tapping a key three times. Precise directions are contained in the operating instructions of the respective devices.

A successful initiation of this read-in mode is conﬁrmed by the system with an AddReady. Now the Z- Wave device has to be activated for reading in. As soon as the Controller recognizes the Z-Wave device, this appears in the Log.

Once the read-in is successfully carried out, the Controller assigns the device an ID. The configuration file of the Z-Wave databank is also assigned. The assigned ID and the associated xml file appear in the log. The zwave.csv is augmented by a new entry (11;NODE_11).

Should you wish to read another device in, the inclusion procedure must be started anew. Appropriate commands are also available for removing Z-Wave devices. Please do not remove any entries manually from the [NODE] section of the Z-Wave.csv. To remove an existing device from the conﬁg- uration, you should use the command: . Then, within 30 seconds, place the Z-Wave device to be removed into the read-in mode as previously described.

When the corresponding Z-Wave device is found, its corresponding entry in the Controller databank is removed. So is the entry in the zwave.csv. The Z-Wave device itself is placed in the exclusion status. If the device being removed is defective or no longer connected, the removal or exclusion of the device can be compelled by using the command .

4.8. Z-Wave Support 169 nomos Documentation, Release 1.1.73

After the system is fully conﬁgured, the process of updating the network topology is recommended. This measure is also recommended when the location of the Z-Wave devices has been changed. The command available for this purpose is .

After successful execution, the Mesh network is set up again or updated. Reading in sometimes proves to be a tricky process. If the devices are not recognized, shorten the distance to your Z-Wave Controller and try again. The BC status report All status reports (assuming the device is supported) are also sent in broadcast without a specific request. This also applies to data for which there are no commands (e.g., battery status, temperature, humidity, etc.). Take note with battery-powered devices that any configuration changes are transmitted and applied only after the most recent (scheduled or manual) reactivation of the device. The data can be evaluated and processed by means of EventServer. All devices are polled once at the system’s start. All reported Nodes and their configuration files appear in the Log. The output for the Z-Wave events occurs after the loading of the Z-Wave configuration is completed.

The status of the reported devices (binary-switch and mutilevel-switch) is polled automatically at 60-second intervals. The polling times for the various data types also show up in the log. The polling times presently cannot be changed. If a device supports Z-Wave Clock Class, its clock’s time is automatically set at intervals of 12 hours.

Report of device status in BC. The status of battery charge of the various devices can also be matched with the respective EventServer deﬁnitions.

4.8. Z-Wave Support 170 nomos Documentation, Release 1.1.73

In case of multilevel, multiple channels or multiple instances, the device name in broadcast is reported or augmented with “-{x}”, to the extent that the command class is supported in more than one instance, e.g. with a 3Kanal RGB Dimmer with the device name :

Alarm classes are also supported and reported separately. Appearing in Broadcast for each Alarm Event is <{Node} ALARM=1> and in return <{Node} ALARM=0>. The Alarm condition of the device can also be reset by command.

There is a ZWAVE command class with the following commands:

4.8. Z-Wave Support 171 nomos Documentation, Release 1.1.73

Command Argument Description includes the device {AddNode} of the Associ- ADDASSOCIATION# {Node},{Group}, {AddNode} ation Group {Group} in the device {Node} ; {Group} is an Index removes the device {RemoveNode} from the {Node},{Group}, {RemoveN- REMOVEASSOCIATION# Association Group {Group} on the device ode} {Node} Wakeup Handling GETWAKEUPINTERVAL provides for the device {Node} a valid range {Node} RANGE# of values for the Wakeup (in seconds) delivers (in seconds) the currently set Wakeup GETWAKEUPINTERVAL# {Node} value for {Node} SETWAKEUPINTERVAL# {Node} sets the Wakeup value (in seconds) for {Node} Commands switches on or off the switch {Node}, {Value} can be: ON/OFF,0/1,YES/NO. {Node}, [{Instanz/CH}], When [{Instanz/CH}] is used, other pos- SETSWITCH# {Value} sible instances (e.g., multiple channel switch) are accessible. When only {Node} is used, a list of all Instances of the device is reported. GETSWITCH# {Node} provides the status of the switch {Node} sets the dimmer {Node} to the value {Node}, [{Instanz/CH}], {Value} or switches {Node} on or off; SETLEVEL# {Value} {Value} can be: 0-99 , ON/OFF , YES/NO . Otherwise as SETSWITCH# GETLEVEL# {Node} provides the value of {Node} delivers the supported modes of the thermostat GETTHERMOSTATMODES# {Node} {Node} SETTHERMOSTATMODE# {Node},{Mode} switches the Thermostat {Node} to {Mode} GETTHERMOSTATSET delivers the setting points of all modes of the {Node} POINTS# Thermostat {Node} SETTHERMOSTATSET changes the setting point of the thermostat {Node},{Mode},{Value} POINT# {Node} in {Mode} to {Value} sets the metering value run up on the device RESETMETER# {Node} {Node} to 0

{Node} can be as follows: x Index of the device (see Log) NODE_x as above, except with preﬁx NODE_ {Name} The name of the device (from the zwave.csv) Examples: Flips on the switch (binary switch) NODE_11 . . Switches the dimmer, Livin- groom Dimmer, to 67%. Returns a list of all recognized Z-Wave devices

4.8. Z-Wave Support 172 nomos Documentation, Release 1.1.73

Initiates updating of the network topology or a restructuring of the Mesh network. issues a list of all instances of the Dimmers StripeRGB switches Channel 1 of the Dimmer StripeRGB to 100 switches off Channel 2 of the switch NODE_34.

4.8. Z-Wave Support 173 nomos Documentation, Release 1.1.73

4.9 Philips HUE Support

The nomos system also supports HUE Leuchten (Lighting) of the Philips corporation. Recognition of the HUE Bridge in the network comes about fully automatically by tapping the „Learn“ Key of the bridge. The command class is then ready to use. No additional configuration file is needed. One can see in the log whether an HUE Bridge is recognized. When an HUE Bridge is on hand, specific data on the bridge will also be returned. The log also gives information on lighting fixtures reporting through the HUE Bridge

Please consult the directions for use of the HUE System on how to configure your HUE Systems or to report the individual lighting fixtures. Technical Data: • Maximum number of lamps: 50 per Bridge • Zigbee Light link: Protocol 1.0 certified • Frequency range: 2400-2483.5 MHz • A Building Automation Licence (BAOS/HS/KNX) is required The BC status output The status of the lighting is polled every 5 seconds and sent in broadcast if there has been a change. This reporting also takes place when the lighting is controlled through HUE’s own App. These reports can be evaluated and processed by means of the appropriate EventServer.

Group Support The nomos system also supports group functions. Docking an HUE Group generates a new, “virtual” lamp with the name {group}. The status is immediately sent in broadcast. HUE Groups can be controlled with the known commands, just as though they were individual lamps; steering and feedback are fully transparent and uniform. A Group is always reported in the broadcast as reachable. An extract of the broadcast output on the Group „G1“ , including its assigned lighting „2_Stehl.“ und „3_Office“, will follow.

Take care in assigning names during the formation of a group that a name already given to a light is not used as the group’s name. If this is permitted to occur, the light rather than the group would be controlled. There is a HUE command class with the following commands:

Command Argument Description GETALLLIGHTS delivers a list of names of all the afﬁliated lights

4.9. Philips HUE Support 174 nomos Documentation, Release 1.1.73

Command Argument Description delivers a list of the IDs of all the afﬁliated GETALLLIGHTIDS lights RENAME# {Light},{Name} renames the {Light} as {Name} POWER_ON# {Light} turns {Light} on POWER_OFF# {Light} turns {Light} off changes the brightness of {Light} to SETBRIGHTNESS# {Light},{Value} {Value} - {‘Value} may be 0 to 255 changes the color tone of {Light}‘‘to SETHUE# {Light},{Value} ‘‘{Value} - {Value} may be 0 to 65,535 changes the brightness of {Light} to SETSATURATION# {Light},{Value} {Value} - {‘Value} may be 0 to 255 changes the color temperature of {Light} to {Value} - {Value} depends upon the tar- SETCOLORTEMP# {Light},{Value} geted light and may at the moment be 153 - 500 (6500K - 2000K) carries out on {Light} a Color Loop or ends SETEFFECT# {Light}, COLORLOOP/NONE same carries out on {Light} a (SELECT) or several {Light},SELECT/ LSE- SETALERT# (LSELECT - for 30 seconds) “Breathe-Cycle” , LECT/NONE or it ends these (NONE) creates a new group with the Name {group} {group}, {light1}, {light2},..., CREATEGROUP and containing the Lamps {light1}, {lightx} {light2}... DELETEGROUP {group} deletes the Group {group} gives all the groups conﬁgued in the HUE GETALLGROUPS Bridge delivers a list of all the lamps assigned to the GETGROUPLIGHTS {group} Group {group}

{Light} can be a lighting ID or the name of the light. {GROUP} is always a group name. Examples: turns the HUE lamp with the „ID 2“ on or off. adjusts the brightness of the HUE lighting with the assigned Name OFFICE to around 50%. Switches the lighting in HUE with the assigned Name OFFICE to a red tone. forms the Group „G1“ with the assigned lights „ID 1“ und „ID 2“ turns off the HUE Group with the Name „G1“.

The changing of a group can be accomplished within a sequence. First the group has to be deleted and then formed again in a second step

4.9. Philips HUE Support 175 nomos Documentation, Release 1.1.73

4.10 mremote Support (commandFusion iViewer support)

The mremote interface extends the nomos infrastructure by one additional communication interface with the Control System Protocol . The protocol used here is optimized especially for operation in an infrastructure with narrow band width, as is usual in, for example, wireless or mobile cellular networks. The deployment and use of this bidirectional* protocol takes place in the background. *Remote station not only executes but also confirms the execution of the query With mremote it is also possible, when using iViewer Software, to integrate a freely definable, graphically supported user interface (GUI) for mobile Apple or Android devices in the nomos infrastructure. Any desired actions from the whole portfolio of nomos services or commands can be called up and served remotely through this interface. Moreover, nomos cross-references the iViewer Project with codes in HTML5. GUI can be employed in this manner on nearly every end-user device, even when using HTML5-capable browsers. An APP is also available for using the HTML5 GUI on IOS or Android devices - App Store- Play Store Information on setting up and working with the iViewer software can be found on the Homepage of the manufacturer. Instructions on how the nomos system controls the iViewer project data and license files are found in the Chapter: Mini–Web Server.. In order to use the HTML5 server on a Mac, MAMP also has to be installed on the Mac system. The HTML5 server is pre-installed on pure Linux-based systems. The mremote service is a prerequisite for operation of the HTML5 server. For the deployment of several nomos systems in the network, multiple access can be achieved with the application of the Relay function. Communication can be „steered“ with this to a targeted system. This means that the control of all systems within the network can function with just one GUI interface, as long as the Joins to the various systems are inscribed with identical functions. Parallel access to various systems is also possible for several Remote Clients. The Control System Protocol supports only the use and transfer of three variable (JOINS) types, which are assigned to the elements in the GUI. These JOINS are distinguished as follows: digital Join binary elements, such as Switch/Key analog Join 2-byte numerical values, for example for Slider serial Joins ASCII, for example, for transmission of textual material, URL‘s and the like Arrays (listed Joins) can also be generated and transferred from each of these types. The JOINS and their functions must now be reported to the nomos system, so that communication or data exchange can take place. The overall definition of the JOINS and their functionality comes from a definition file, mremote.csv. Once the JOINS are definied, they can also be manipulated internally with appropriate commands. The JOINS can also be applied directly, for example, in the Logic Module (see Chapter: Logic ). Defined Joins or their value content are automatically buffered and transmitted to the Client when connection is made. This action can be specifically blocked for any JOIN if necessary (NOINIT). Actions of the JOINS

4.10. mremote Support (commandFusion iViewer support) 176 nomos Documentation, Release 1.1.73

As already described, the value content of the JOINS is automatically buffered and transmitted automatically upon connection with a Client. If the value content of a JOIN is changed with the Control System Protocol , correspondingly defined JOIN Actions are carried out. Changing the JOIN content with the nomos system Commands serves only to update the JOIN for the Client. Therefore, no Actions are taken. The definable Events for the revision of the JOINS also update only the JOINS on the Client and carry out no defined Actions. If Events are also supposed to initiate Actions, these must be defined in the {Local-Action}. With digital JOINS, this applies to the {Push-Event} only if the condition „TRUE“ is the mremote.csv file The mremote.csv is found in the folder .\misc of the nomos Project Index. This file is a prerequisite for communication between the iViewer App, or the nomos App, and the HTML5 server in use. The mremote.csv describes the overall functionality of the actual GUI application and forms the communication gateway to the nomos infrastructure. The mremote.csv definitions allow for such options as, for example, automatic scaling of analog values, feedback definitions, comparable „push and hold“ functionality and much more. Therefore, this need not require independent attention on the Client side. For the use of the iViewer software, therefore, the complete logic and also functions for updating the respective status can be ignored. Structure of the definitions table:

Type: csv ﬁle Location: .\{projectPath}\misc\ Name: mremote.csv Length: 10,000 lines/entries, 100 LIST deﬁnitions Event: BC, Status Export: - Licens: yes

The mremote.csv is composed of six sections: [CONFIG]; General configuration of the Interface Parameter [DIGITAL]; Definition of the digital JOINS [ANALOG]; Definition of the analog JOINS [SERIAL]; Definition of the serial JOINS (up to 8K textual content per JOIN) [LIST={aJOIN}]; Definition of the list with the index x (x corresponds to the analog Join number for the list in the GUI Designer) (max. 250 elements/lists) [PAGE]; matches the page a Client calls up to take any desired action with the names sent to the iViewer or HTML5 server. Structure: • [CONFIG];Section ACTIVE;YES Activates/deactivates the Web server „YES“ (default)= active,

4.10. mremote Support (commandFusion iViewer support) 177 nomos Documentation, Release 1.1.73

„NO“ = not active DEBUG;YES Extends LOG output „YES“ = active, „NO“ (default) = not active PORT;{Port} Port number for the connection 5500 (default) in progress PASSWORD;{Password} Deﬁnition of a password from the mremote Client, which is ex- pected for establishing the connection PORTRAIT;{Action} nomos sequence carried out by turning the iPod/iPhone into the ver- tical position LANDSCAPE;{Action} nomos sequence carried out by turning the iPod/iPhone into the horizontal position CONNECT;{Action} nomos sequence carried out when connection is made to a mremote Client GUI_IP;{IP,AUTO} Server IP or host’s name, which is automatically transmitted to the Client during Project Download from the integrated Web server. The local IP is automatically entered on AUTO GUI_PORT;{Port}/AUTO Server port, which is automatically transmitted to the Client during the Project Download from the integrated Web server. On AUTO , the deﬁned port number under PORT is entered automatically. 1235 (default) SPEECHLANGUAGE;{Lang-Setting} selects the language for the speech output of the device control. (see Chapter Device Control).‘‘en_US‘‘ (Default:) SPEECHVOICE;{Voice} chooses the voice for the speech output of the device control. (see Chapter Device Control) A list of the possible languages and voices is found here: http://dragonmobile.nuancemobiledeveloper.com//public/index.php?task=supportedLanguages • [DIGITAL];Section

{Nummer};{Typ};{Push-Action};{Release-Action};{Push-Event};{Release-Event}; {Option};{Local-Action} Structure of a digital Join Explanation:

{Number} Number/address of the digital JOIN (dJOIN) {Type} Type of button, possible values: 0,1,# normal JOIN actions. With the inclusion of „#“ the incoming value is buffered and the action can be transmitted by means of „\#“. TOGGLE* lock button in/to current state (switch) INTERVAL={x,y} promptly executes {Push-Action} and, after y (initial delay in ms) the {Release-Action}. With button depressed the

4.10. mremote Support (commandFusion iViewer support) 178 nomos Documentation, Release 1.1.73

{Release-Action} is repeated in preset time intervals (x in ms). If (y) is not assigned, it is y=0. XOR={x}* refers to the button of a group x of buttons that are mutually blocking. x must be a number. In using this type, the {Option}NOCACHE is automatically fixed. HOLD={x} executes {Push-Action} when button is depressed for less than x ms. Otherwise, after x ms elapse, {Release-Action} is immediately carried out {Push-Action} Script or nomos Sequence, which is execute when a key is pressed {Release-Action} Script or nomos Sequence carried out when key is released {Push-Event} nomos Match Sequence, which puts the button into the „pushed“ state. If „match“ condition is met, {Local-Action} is also carried out. {Release-Event} nomos Match Sequence, which puts the button into „released“ state. {Option} Additional configuration options, possible values: (Several options can also be prescribed. These options can be separated with „,“) NOCACHE Forces updating of a JOIN. Otherwise, actualization is done only by changing the condition. NOINIT Prevents the automatic updating of a JOIN upon connection with a Client AUTOFEEDBACK Ensures that the value sent from the JOIN is immediately written back again to the Join. Therefore, identical in function to “simulate feedback” flag of the iViewer, except that all connected Clients are immediately actualized. DELAYFEEDBACK=x Blocks the “authentic” feedback (namely, the match) of a JOIN as long as x milliseconds have elapsed since the last (!) action of the Join. Matches arriving in the interim are automatically stored in an interim memory and the last value is written back to the Join after this time has elapsed. This prevents AUTOFEEDBACK and a correct match from colliding with one another. {Local-Action} Script or nomos Sequence, which is also carried out locally in the event of a successful match. Apart from the Standard Argument wild card \#, the lists’ internal index \& is also a possibility with listing. The Local-Action of a Join is also carried out, if a correspondingly defined DELAYFEEDBACK has not yet elapsed but is possible in the lists’ internal index \&. *The Simulate Feedback Flag must not be set when this option is used • [ANALOG];Section {Number};{Condition};{Scaling};{Action};{Event};{Option};{Local-Action} Structure of the definition of an analog Join Explanation:

{Number} Number/address of the analog JOIN (aJOIN) {Condition} Match condition, which the Event Argument must fulﬁll. The arriving value is buffered and the action can be transmitted by means of „\#“. Possible values:

4.10. mremote Support (commandFusion iViewer support) 179 nomos Documentation, Release 1.1.73

{empty} or # Wild-card match (always met) {<>=value} Argument must be smaller/larger/equal {value}, Combining comparable operators is possible {Scaling} converts the maximum numerical value of a JOIN (65535) in {Scaling} (=numerical value). The conversion is made in two directions. {Scaling} can also be a nomos Match Sequence, such as \%GETCTIME=\*|, in order to align the scaling dynamically to running time. {Action} Script or nomos Sequence that is to be executed with arriving JOIN activities. Content of the Join can be included or passed on with \# as argument. {Event} nomos Match Sequence with which the JOIN is supposed to be synchronized. Argument Filters, such as \*, \?, \% and many more known from the Event server are also usable here. {Option} Additional configuration options, possible values: (Several options can also be prescribed. These options can be separated with „,“) NOCACHE Forces updating of a JOIN. Otherwise, actualization is done only by changing the condition. NOINIT Prevents the automatic updating of a JOIN upon connection with a Client AUTOFEEDBACK Ensures that the value sent from the JOIN is immediately written back again to the Join. Therefore, identical in function to “simulate feedback” flag of the iViewer, except that all connected Clients are immediately actualized. DELAYFEEDBACK=x Blocks the “authentic” feedback (namely, the match) of a JOIN as long as x milliseconds have elapsed since the last (!) action of the Join. Matches arriving in the interim are automatically stored in an interim memory and the last value is written back to the Join after this time has elapsed. This prevents AUTOFEEDBACK and a correct match from colliding with one another. ACTIONINTERVAL=x Requires that a minimum period of time (x in ms) elapses when an action is initiated. During this waiting period, arriving events are ignored. Only the final value of the event is stored and the action is carried out after the pause, using the last value as agument. {Local-Action} Script or nomos Sequence, which is also carried out locally in the event of a successful match. Apart from the Standard Argument wild card \#, the lists’ internal index \& is also a possibility with listing. The Local-Action of a Join is also carried out, if a correspondingly defined DELAYFEEDBACK has not yet elapsed but is possible in the lists’ internal index \&. • [SERIAL];Section {Number};{Condition};{Action};{Event};{Option};{Local-Action} Structure of the definition of a serial Join Explanation:

{Number} Number/address of the serial JOIN (sJOIN)

4.10. mremote Support (commandFusion iViewer support) 180 nomos Documentation, Release 1.1.73

{Condition} Match condition, which the Event Argument must fulfill. The arriving value is buffered and the action can be transmitted by means of „\#“. Possible values: {empty} or # Wild-card match (always met) {String} Argument must be identical to {String} {<>=value} Argument must be smaller/larger/equal {value}, Combining comparable operators is possible {Action} Script or nomos Sequence that is to be executed with arriving JOIN activities. Content of the Join can be included or passed on with \# as argument. {Event} nomos Match Sequence with which the JOIN is supposed to be synchronized. Argument Filters, such as \*, \?, \% and many more known from the Event server are also usable here. {Option} Additional configuration options, possible values: (Several options can also be prescribed. These options can be separated with „,“) NOCACHE Forces updating of a JOIN. Otherwise, actualization is done only by changing the condition. NOINIT Prevents the automatic updating of a JOIN upon connection with a Client AUTOFEEDBACK Ensures that the value sent from the JOIN is immediately written back again to the Join. Therefore, identical in function to “simulate feedback” flag of the iViewer, except that all connected Clients are immediately actualized. DELAYFEEDBACK=x Blocks the “authentic” feedback (namely, the match) of a JOIN as long as x milliseconds have elapsed since the last (!) action of the Join. Matches arriving in the interim are automatically stored in an interim memory and the last value is written back to the Join after this time has elapsed. This prevents AUTOFEEDBACK and a correct match from colliding with one another. ACTIONINTERVAL=x Requires that a minimum period of time (x in ms) elapses when an action is initiated. During this waiting period, arriving events are ignored. Only the final value of the event is stored and the action is carried out after the pause, using the last value as argument. {Local-Action} Script or nomos Sequence, which is also carried out locally in the event of a successful match. Apart from the Standard Argument wild card \#, the lists’ internal index \& is also a possibility with listing. The Local-Action of a Join is also carried out, if a correspondingly defined DELAYFEEDBACK has not yet elapsed but is possible in the lists’ internal index \&. • [LIST={x}];Section

{Join-Type=Number};{Master-Join-Type=Number};{Event};{Optionen};{Local-Action} Structure of the deﬁnition of a Listed Join Explanation:

{Join-Typ=Number} describes the Join for which List Support is desired, for example, SERIAL=7 or ANALOG=3 or DIGITAL=23; only SERIAL actually makes sense

4.10. mremote Support (commandFusion iViewer support) 181 nomos Documentation, Release 1.1.73

{Master-Join-Type=Number} describes the Join, to which the previously mentioned Join is supposed to be attached. I.e., when the Master Join from the list sends an event, an event is simulated for the previously mentioned Join; syntax as above {Event} the Match Sequence to generate a list entry, the match takes place by removal. {Options} only NOINIT currently supported {Local-Action} nomos Sequence that is to be executed in case of a successful match. Apart from the argument \# , additionally \& for the lists index is possible as a wild card • [PAGE];Section {Page Match};{Action}; Structure of the deﬁnition of a Page Event Explanation:

{Page Match} Name of the page called up on the Client {Action} Script or nomos Sequence that is to be carried out in case of a successful page match. The content of the page match can be inscribed or transmitted with \# as argument. Examples for Deﬁnitions [DIGITAL] Section:

{Number};{Type};{Push-Action};{Release-Action};{Push-Event};{Release-Event};{Option};{Local- Action}

10;;;;;;NOCACHE; Registers a JOIN (10) without further function. This possibility serves as, for example, a wild card or a cache of possible JOIN values, which can be correspondingly engaged by means of the ;0/2/12-\%=0>;NOCACHE; Defines a JOIN (2) for a binary display. The display reacts to the event of a KNX group address; in this example, to the address 0/2/12. If the condition for the {Push-Event} is „TRUE“, the {Local-Action} will also be carried out and the Script home.myh started. This type of definition can be used, for example, as a Event Server. 15;1;; The simplest definition of a JOIN. Here the JOIN (15) is assigned a simple function, as for example is the case with IR-controlled devices.

66;TOGGLE;;;|MUTE=ON|;MUTE=OFF| ;NOINIT; A definition of a JOINS (66), which generates an inactive button when using the iViewer GUI. Also set forth are two functions, which are respectively carried out in a change of status. The status is automatically updated by the corresponding event. If the condition for the {Push-Event} is „TRUE“, the {Local-Action} is also carried out and the sJOIN inscribed with the text „mute“. The function is an example of the Mute Control on an Apple Mac Client. 54;HOLD=800;;; Defines the JOIN (54) with a function, which carries out the {Push-Action}, when the button is depressed more briefly than the „hold time“ (ms). If the button is depressed longer than the prescribed hold time, the {Relase-Action} will immediately be executed when the hold time elapses, even if the button is still being pressed.

4.10. mremote Support (commandFusion iViewer support) 182 nomos Documentation, Release 1.1.73

18;INTERVAL=500;;; Deﬁnes the JOIN (18) with a function, which executes the {Push-Action} at intervals of 500 ms when the botton is being pressed. The function is typical for the control of accoustic volume that is to be increased slowly by pressing a key. The incremental pace of increase in this example was given by variables. The employment of variables offers the possibility to alter the size of the increments dynamically with the running time.

10;XOR=10;;;GETPLAYERSTATE=PLAYING;;NOCACHE 11;XOR=10;;;GETPLAYERSTATE=PAUSED;;NOCACHE 12;XOR=10;;;GETPLAYERSTATE=STOPPED;;NOCACHE

Deﬁnition of a Group (10) of buttons (10,11,12) that lock on themselves. The function synchronizes the status of all buttons in an XOR group. Only one button here can assume the „pushed“ status. If that buton is pushed, the {Push-Action} of its associated JOIN is triggered. Actualization of the buttons can also be done through {Push-Event}. Examples for the Deﬁnitions [ANALOG] Section:

{Number};{Condition};{Scaling};{Action};{Event};{Option};{Local Action}

1;#;100;;|VOL=\*|; Receives the analog JOIN 1 and scales the received value to „100“. The scaled value is passed on with the command {Action}. The {Event} deﬁnition revises the JOIN so that a corresponding value can be received. This is the typical case with, for example, a Volume Slider

3341;#;255;;1/2/9-\%=\*>;NOCACHE, ACTIONINTER- VAL=300, DELAYFEEDBACK=800;; Function as previously described. But additional options are also deﬁned here. With the NOCACHE option, the JOIN is also revised with each incoming value, regardless of whether or not a value change is made. With ACTIONINTERVAL, a sending buffer is activated, which allows the {Action} to be carried out only every 300ms. DELAYFEEDBACK delays the actualization of the display to the Client, when it is triggered by {Event}. The delay period begins after no more value changes arrive from the JOIN. This is a KNX-typical Dimmer/Slider function. It is particularly important here that the communication speed of the mremote service be aligned with the speed of the targeted system.

12600;#;100;;Z16_VOLUME=\*|;NOCACHE, ACTIONINTERVAL=300,DELAYFEEDBACK=800; Function as above, but with a scaling of 100 for the control of volume for a NUVO multiroom system. 30001;#;<[ATV-1]>\%GETCTIME=\*|;;<[ATV-1]>\%GETPTIME=\*|; Function for a dynamic display. The {Scaling} of the display is made permanently compatible with an Event Match. This example serves for the display of running time of music titles. Since the running times of these individual items vary, the corresponding scaling has to be adjusted. Examples for the Deﬁnitions [SERIAL] Section:

4.10. mremote Support (commandFusion iViewer support) 183 nomos Documentation, Release 1.1.73

{Number};{Condition};{Action};{Event};{Option};{Local Action}

2;#;;|GETTITLE=\*| Describes JOIN (2) with the relevant iTunes title 2152;;;2/3/13-\%=\*>;NOCACHE;; Describes JOIN (2152) with the value content of the KNX group address 2/3/13. The JOIN is also updated by the NOCACHE option, when no value has been changed. This example is typical of, for example, a KNX temperature display.

50000;#; This function receives a text from the JOIN (50000) and passes it along by means of „\#“ to the {Action}. Another function describes or clears this JOIN again. This function is typical of the sending of text messages. 50001;Password; This function receives a text through JOIN (50001) and compares the text with the content of the {Condition}. If the result is „TRUE“, the {Action} is carried out. 30005;;;<[ATV-1]>\%GETPTIME{%02m:%02s}=\*|;; This function describes the JOIN (30005) with a value. The value is received from GETPLAYTIME and converted in form so that the display is rendered in minutes and seconds. A system variable is used here for the command class. 210;;;\%<100/0/8\%=\*;;; This function receives an {Event} for the address 100/0/8 from the KO Gateway of the GIRA Home server. As soon as a value change is recognized, the matched value is transmitted to the {Local Action} and executed. The value is formatted to two decimal places with the function {%*1.00}. A unit „A“ is also attached 30002;;;<[ATV-1]>\%|TITLE=\*|;NOCACHE;; This function describes the JOIN (30002) with a value. The value is received from TITLE. Whenever the {Event} receives data, the {Local Action} is also carried out. This function is typical of the reception of, for example, a title identification from AppleTV. With each reception, the title information will also send the relevant URL of the covers. The command class is also transmitted here by means of system variables. Additionally, the network data (IP and port address) of the Web server for broadcast is also passed on with fixed variables. Further information on working with system variables may be obtained from the Chapter: Working with System Variables Examples for the Definitions [LIST=n] Section: With lists of several JOINS, the list is only erased when the Event for the 1st Join definition contained in the list is positive. Otherwise, the content of the list is merely overwritten.

{Join-Type=Number};{Master-Join-Type=Number};{Event};{Optionen};{Local-Action} Generation of a list of all iTunes-Playlists:

[SERIAL];91;#;;GETALLPLAYLISTS=\*OK; In the match sequence above, a serial JOIN delivers a list of all Playlists:

4.10. mremote Support (commandFusion iViewer support) 184 nomos Documentation, Release 1.1.73

Mediacenter|Music|....|recently added|

[LIST=1];SERIAL=91;DIGITAL=90;\*|;; On this List (1), a subtractive match in the list definition takes place with \*| and the list is filled by this. At the same time, the virtual array of the serial Join 91 is combined with the digital Join 90, which is defined in GUI Designer as listing element. Example for Definitions [PAGE] Section:

{Page Match};{Action};

Home; When the page „Home“ on the Client is opened, the {Action} is carried out Subpage_\*; Matches the name of the subpage and transmits the value to the {Action}

Relay Function One also has the possibility to divert the mremote control through RELAY to other nomos systems. To do this, please enter as nomos sequence:

RELAY={IP}:{Port},{MAC}; Structure of the deﬁnition of a RELAY Deﬁnition in the Section [DIGITAL] Explanation:

{IP} IP of the remote mremote service to which communication is to be routed. {Port} Port of the remote mremote service to which communication is to be directed. {MAC} {MAC} of the remote mremote service to which communication is to be routed. When the MAC is identified, a WOL packet is sent before the RELAY is set up. If the RELAY function is initiated as Action, the local Mac establishes a connection to a remote Mac. As soon as the connection is made, all Actions and Events are transparently redirected. The local JOIN definitions have no effect in this mode; only the RELAY Actions are still evaluated locally. The local Mac in this mode behaves as being fully transparent. One uses this technique, for example, with systems of nearly the same configuration. A uniform GUI may be generated in this way for all nomos systems one wishes to control. The nomos systems can then be individually engaged by structuring the RELAY appropriately. Examples for the RELAY Definitions:

{Page Match};{Action};

530;1;RELAY=192.168.1.23:5500,C82A1400D30; Opens the RELAY to the remote nomos system. There can never be more then one active RELAY connection. If a new RELAY is set up while there an existing RELAY is connected, the existing connection is automatically broken off. 531;1;RELAY=OFF; Closes the RELAY and activates the local JOIN deﬁnitions

4.10. mremote Support (commandFusion iViewer support) 185 nomos Documentation, Release 1.1.73

The RELAY function cannot be combined with nomos sequences. For the manipulation of the JOINS, the following commands are available:

Command Argument Description SETDIGITALJOIN# {Address},{Value} Assigns to JOIN {Number} a new {Value}. SETANALOGJOIN# {Address},{Value} Assigns to JOIN {Number} a new {Value}. SETSERIALJOIN# {Address},{Value} Assigns to JOIN {Number} a new {Value}.

Examples: Sets the digital JOIN 146 to the value of „1“. This command does not affect Actions of the JOIN deﬁnitions but merely updates the JOIN to the Client. As the previous, except that here the analog JOIN 50 is inscribed with the value 44. As above, except that here the serial JOIN 100 is inccribed with the text „Power ON“.

4.10. mremote Support (commandFusion iViewer support) 186 CHAPTER 5

Miscellaneous

5.1 Working with System Variables

The nomos system supports the employment of System Variables. They can store any desired values by using of the ...VAR commands from the class. Or they can fix stored values as well as apply them. This is practical for large installations because, for example, Script callups can be manipulated in this way, and volumes or system status can be defined and stored. Apart from their versatility in the Logic Module, matches, classes or commands can be defined throughout the system by means of Sysvars, which can substitute for running time. Sysvars can therefore be deployed nearly anywhere. Sysvars can be written on the running time in a file, sysvars.csv, or in the temporary memory cache. With Linux versions, the name of the file is fixed. With Mac systems, sysvars.csv can be relabeled, using the following option in the PrefPane. When working with the optional definitions file, these can also be found in the Root Index of the corresponding project. If this file cannot be located or is unavailable, the Default Datei is used automatically. Recourse to this method serves to control, for example, specific system configurations with different files. Changes can be written into the optional file. Should Standard Values again be used, the optional file merely needs to be removed or deactivated with Check Box in the PrefPane.

The writing or overwriting of entries in the sysvars.csv can also be blocked (see Command LOCKVARS=ON/OFF). In this case, the changes or new entries are not written directly into the data storage medium but are held in a temporary cache. After a New Start, LOCKVARS=ON will read out only those values in the file. Temporary values are lost. This behavior can be modified during the running time. A LOCKVARS=ON does not write the current content of the temporary memory cache into the file! A LOCKVARS=ON does not write the current content of the temporary cache into the file! Especially when using CF or SD cards, as are employed in the Linux variant of the nomos Box, one should prevent permanent inscription of the data storage medium. The Default setting for Linux versions is therefore also LOCKVARS=ON. Structure of the Definitions Table:

Type: csv ﬁle Location: .\{projectPath}\misc\ Name: sysvars.csv (is generated automatically, if not present)

187 nomos Documentation, Release 1.1.73

Name opt.: as conﬁgured in the PrefPane (Mac OSX only). Length: 10,000 lines/entries Event: - Export: - License: -

The sysvar.csv contains no sections The values of the variables are entered automatically when the command sequence of the [{Variablenname}] is found.

Structure of the ﬁle: {Name};{Content}; Explanation:

{Name} Name of the variable; callup then takes place by assigned [{Name}] {Content} Value charge of the variable by which the wild card [{Name}] is replaced. Examples:

stores a variable named „Startvolume“ with the value 33 sets the system volume to the value of the variable „Startvolume“ reports all current variables and their value charge. Dynamic System Variables: The so-called dynamic system variables are generated automatically. These variables are deﬁned upon System Start and serve, for example, the automatic transfer of such system-speciﬁc parameters as screen resolution, IP address, URL of the project path and many more.

[SYSTEM_IP] - current IP [SYSTEM_SERIAL] - actual serial number of the hardware [SYSTEM_MAC] - current MAC address of the hardware [SCREEN_X] - x resolution of the viewing screen [SCREEN_Y] - y resolution of the viewing screen [BUTTON_SIZE] - current height of the button bar [HOMEDIR] - current index [PROFILE] - current proﬁle name (short name) [PROJECT] - current project path [TIME] - current system time (in the KNX EIS3 format) [DATE] - current system date (in the KNX EIS3 format) [OEM_NAME] - actual OEM name of the Demon

[ARG] - reserved for the argument transferral (see Kapitel Script) [GARG] - reserved for the argument transferral (see Kapitel Script)

5.1. Working with System Variables 188 nomos Documentation, Release 1.1.73

All variables can be overwritten, i.e. a manual definition takes precedence. The command GETALLVARS always recovers all variables; for example, if SYSTEM_IP in the .csv is defined, the variable appears twice in the response sequence. With the integration of the dynamic system variables, a powerful tool to construct profile dynamically is placed at one’s disposal. Nearly all settings can be transmitted by means of system variables. CONFIG settings/sections of the respective definition files, such as IP or Port Addresses can also be transmitted by means of system variables. It becomes possible in this way to control specific settings of the configuration from the sysvars.csv alone. Changing the variables during the running time must be done with the SETVAR command. Example (webserver.csv):

[CONFIG]; ACTIVE;YES DEBUG;[DEBUG] PORT;1234 GUIPORT;1235 DVD_PATH;[HOMEDIR]/Movies/

With the deployment of the dynamic variable [HOMEDIR] , the parameter DVD_PATH is automatically augmented with the entry „/Movies“ from the URL of the currently registered user and then transmitted. Naturally, this entry can also be made directly in the webserver.csv , although this would defeat the purpose of a reproducable configuration file. The option of Debug Mode is also set with a variable. One can therefore program the activation or deactiva- tion of this mode specifically and especially system-wide. System variables, like field variables, can also operate automatically, if their value charges are separated with a „|“. A written entry targeted at an index is at the moment not possible! In the command class SYS are the following commands for using Sysvars:

Command Argument Description GETVAR= {Variablename} reads the value of a system variable alters the value of a system variable or registers SETVAR= {Address},{Value} one DELVAR= {Variablename} deletes a system variable gives all deﬁned variables, including their value GETALLVARS charges locks or enables the inscription of the variables LOCKVARS= {ON/OFF} on the storage medium

5.1. Working with System Variables 189 nomos Documentation, Release 1.1.73

Command Argument Description continues the current sequence until the Sys- var {Variablename} has taken on the value {Value} . If {Timeout} (in ms) is also entered, a wait of {Timeout}-milliseconds {Variablename}, WAITVAR= is imposed. If the time has elapsed and {Value}{,{Timeout}} {Variable} never contained {Value} , the rest of the sequence is NOT completed but rather ignored. A time-dependant "IF -> THEN" can be replicated here.

Examples: The Variable „Test“ with the content „Value1“, „Value2“, „Value3“, „Value4“ is written in this way into the sysvars.csv . The separation sign „|“ indicates here the index of the respective value charges. The query with a format parameter is now used to deliver the value of the second charging of the Variable „Test“ with a length of 1, meaning a single value charge, from the previously registered variable. The result is accordingly: GETVAR{%l2,1}=Value2|OK The same query, except now with a length of 2. The result is accordingly: GETVAR{%l1,2}=Value1|Value2|OK executes the SAY command only when the Sysvar MESSAGE has the content "HELLO" within 3 seconds (or already has this upon calling up WAITVAR).

5.1. Working with System Variables 190 nomos Documentation, Release 1.1.73

5.2 Mini- Webserver

Mini- Webserver (Command Fusion Extension) A small Webserver is integrated into the nomos system. Its mission is to make information available in the form of content. This content can be provided by third parties. For example, the cover image for the iTunes song currently playing is always provided at the stationary Web address. Similarly, the station logotype insignia of the television channel being viewed or the cover to a DVD being played can also be called up. Structure of the Deﬁnitions Table:

Type: csv ﬁle Location: .\{projectPath}\misc\ Name: webserver.csv Length: 100 lines/entries (aliases) Event: Export: - License: -

The webserver.csv is composed of 2 sections: [CONFIG]; General configuration of the interface parameter [ALIASES]; Definition von datapoints that are to be received and evaluated with KNXnet/IP. Structure: • [CONFIG];Section ACTIVE;YES activates/deactivates the webserver „YES“ (default)= active, „NO“ = inactive DEBUG;YES extends LOG output „YES“ = active, „NO“ (default) = not active PORT;{Portnumber} Port of the Webserver. For {Portnumber} one should use a Port > 1024 (default). GUIPORT;{Portnumber} Port for the GUI upload (iViewer) of the Webserver. For {Portnumber} one should use PORT + 1 (default=1235) if available. DVD_COVER;{Image name} fixes the name of the DVD cover (default: preview.jpg) DVD_PATH;{Path to the DVD-Indices} Start path of the DVD index. E.g. „DVD_PATH;/Users/mmh/Movies/“ for the local folder „Movies“ • [ALIASES];Section The Webserver to convert all queries beginning with "alias/" to another URL with help of the webserver.csv . A maximun of 100 entries possible. {Aliasname};{URL} Name of the Alias; assigned URL Examples for the Definitions [ALIASES] Section:

5.2. Mini- Webserver 191 nomos Documentation, Release 1.1.73

– Static: my_pix;http://www.mremote.de/Start_files/droppedImage.png Callup: http://{mmh-ip}:{Webserver-Port}/alias/my_pix – With Sysvar firmly defined: Picture_1;[IMAGE_LINK_1] Callup: http://{mmh-ip}:{Webserver-Port}/alias/Picture_1 Replaces Picture_1 with the URL previously stored in the sysvar IMAGE_LINK_1. The evaluation of the sysvar takes place during running time. – With matching and multiple Sysvars: Photo_\*;[START][IMAGE_LINK_\#] Callup as above, but now dynamic: Photo_x is replaced by the sysvar IMAGE_LINK_x, if this is defined. The argument is inserted before the sysvar is replaced. – With Matching, without Sysvars: Picture_\*;http://www.mremote.de/Image_\# Callup as above, but the index with the picture is made part of another URL. Application: – iTunes Cover Support The following URLs are made available by the Webserver: http://{IP}:{Portnumber}/itunes_current.jpg shows the cover of the iTunes title being played http://{IP}:{Portnumber}/itunes_ID_{ID}.jpg shows the cover of the iTunes title after ID is called up http://{IP}:{Portnumber}/itunes_album_{Name}.jpg shows the cover of the iTunes album upon callup of the album’s name. – Remote (AppleTV) and SONOS Support The following URLs are made available by the Webserver: http://{IP}:{Portnumber}/{Class}_current.jpg shows the cover of the currently playing title of the engaged class, as defined in the remote.csv or sonos.csv. – XBMC Support The following URLs are made available by the Webserver: http://{IP}:{Portnumber}/{Class}_current.jpg shows the cover of the currently playing title of the engaged class, as defined in the xbmc.csv . http://{IP}:{Portnumber}/{Class}_ ALBUMID_{AlbumID}.jpg shows the cover of the Album ID of the Player of the class in use, as defined in the xbmc.csv . – DVD-Cover Support (DVD Player.app): The following callups are possible: http://{IP-Address}:{Portnumber}/dvd_current.jpg reads out the current DVD title and seeks in {DVD_PATH}/{DVDTitle} a preview.jpg file, then brings this back. {DVDTitle} is automatically generated meanwhile from the information in the running DVD. http://{IP-Address}:{Portnumber}/dvd_{DVDTitel }.jpg Seeks in {DVD_PATH}/{DVDTitel } a preview.jpg file and retrieves this. Example: http://192.168.50.55:1234/dvd_Casino%20Royale.jpg html- suffixes (%) are automatically converted. preview.jpg can be located at any depth

5.2. Mini- Webserver 192 nomos Documentation, Release 1.1.73

in the folder to be searched – TV-Logo Support (eyeTV.app): Create a sub-folder “web” in the misc folder. In this folder the broadcaster’s logos have to be filed as *.png or *.jpg . Care must be taken with the naming convention as follows: tv_{Sendername}.jpg. {Sendername} must correspond exactly to the name that is retrieved with the command GETCHNAME of the command class . Example: Set up Logo files tv_SAT.1.jpg or tv_SAT.1.png for the broadcaster SAT1 sub-index „./misc/web“ . The logos can be loaded down by entering the file name from the Webserver, for example, in order to make a program list. For this purpose there is also the firmly defined tv_current.jpg . The callup: http://{IP-Address}:{Portnumber}/tv_current.jpg or /tv_current.png reads out the current broadcaster and provides the corresponding logo (if available). There are so-called Dummies for all graphics. These are reported when no corresponding graphics file is found. These files also have to be inserted into the ./misc/web folder and are named as follows: ‘’itunes_dummy.jpg‘‘ , dvd_dummy.jpg, tv_dummy.jpg {AppleTV}_dummy.jpg {sonos}_dummy.jpg or with suffixes as .png files. Capitalization of letters plays no role with either file naming or URL callups. The graphics buffer was defined at a maximal 20MB. This should allow all graphics to be represented. Nevertheless, depending upon the application, care should be taken to keep the files small and to use only the pixel size that is necessary for the presentation. – Support of free image files: The desired files have to be lodged in the folder ./misc/web . Files placed there must not collide with the features of the Webserver. An ITUNES_CURRENT.jpg in the web folder would not be retrieved if, for example, a remote class existed with the name ITUNES. http://{IP-Address}:{Portnumber}/{Filename}.jpg http://{IP-Address}:{Portnumber}/{Filename}.jpg provides the image file anchored in the URL. Example: The desired file (first-floor-corridor.jpg) must be part of the folder ./misc/web. The targeting system has the IP Address 192.168.50.19 and the Web- server is reachable at Port 1234. The correct callup is then: http://192.168.50.19:1234/first-floor-corridor.jpg For callups with ’/’ in the file name, ’/’ is replaced with a BLANK. This may be the case with, for example, television or musical titles.

5.2. Mini- Webserver 193 nomos Documentation, Release 1.1.73

5.2.1 Mini- Webserver (Command Fusion Extension)

The deployment of the project data of the iViewer Software (GUI Designer Project Data) also takes place on the Mini-Webserver. The iViewer and the GUI Designer are products of CommandFusion. Their application is supported completely by nomos system. Instructions on installing and working with the iViewer software is found on the Homepage of the manufacturer. Information for the installation and linkup with the nomos system can be found in the Chapter: mremote Support (CommandFusion iViewer Support). Furthermore, the nomos system recodes the iViewer Project into HTML5. This allows GUI to be put to work as well on nearly every end-user device that also makes use of HTML5-capable browsers. An APP is also available for the application of the HTML5 GUI to IOS or Android devices. - App Store - Play Store To enable the use of the HTML5 Server on a Mac, an additional MAMP must be installed on the Mac System. For pure Linux-based systems, the HTML5 Server is pre-installed. The mremote service is a prerequisite for operating the HTML5 Server. Data archive (project file) The entire content of the GUI Designer’s project index (namely, project file *.gui, *.asv and all of the image files) has to be copied to the nomos system. Sub-indices are also supported to the extent that these are found in the project structure. The target index for project data on the nomos system is:

.\{projectPath}\misc\mremote\ iViewer Upload Service The iViewer Upload Service is provided through the Mini-Webserver. The maximum size of GUI Upload comes to 20MB. When the data is introduced into the nomos system, the File URL must be entered in the settings of the corresponding APP. The File URL is structured as follows: http://{IP-nomos system}:{Portnumber}/{Projectfile}.gui The {Portnumber} for the Download Service, unless defined otherwise in the settings of the webserver.csv under GUIPORT, is always the ports +1 of the Mini-Webserver. If Standard Values were being used, the Port address would be 1235. If only a .gui file has been placed in the folder structure, the designation of the project file is not necessary.

5.2. Mini- Webserver 194 nomos Documentation, Release 1.1.73

The Control System settings are automatically down-loaded with the project data, if they are not already present in the .gui ﬁle. If the data of the Upload Server is not automatically acquired, these can be also be prescribed individually in the mremote.csv of the [CONFIG] section. The CommandFusion iViewer Pro Versions require an additional license ﬁle. The procedure to obtain such a license can be found on the Homepage of the manufacturer. The device license, which you will receive upon registering with the manufacturer, contains the following information:

Device Name: DMTABGTHFKYC Device ID: C9F80881-B67B-43B4-B272-4GF04FFF55D2 License code: 567A5575D1830BD2EFD0621DB7C53095 To ensure that these data are then also transmitted with the Project Upload, you proceed as follows: Mac OSX Create a .txt file with the registration information. Please make sure that no blank spaces are left at the end of the lines, which need to be followed directly by a LF (Line Feed) or CR (Carriage Return). Any file name you choose can be assigned to the .txt file. It may be becessary with older versions to change License code: into Registration Code:. Open the nomos system configuration (PrefPane) in the OSX system settings and pull the .txt file with Drag & Drop to the „Licensing“ field. Then follow the dialogue.

5.2. Mini- Webserver 195 nomos Documentation, Release 1.1.73

You may report any number of Keyfiles to the nomos system. Linux systems With Linux-based systems, the registration information is summarized in a text file (remote_licenses.csv) . This file is found in the folder ./config. If that file is not present, the file would have to be introduced there. Line by line information is entered as follows:

Device Name;Device ID;License code Typical example:

DMTABGTHFKYC;C9F8765381-B67B-43B4-B272-4GF04FFF55D2;877A5575D1830AB563FD0621DB7C53095 DMTABGTAVGYC;C9F823451-B67B-43B4-B272-4GF04FFF55D2;907A5575D1830AS56FD0621DB7C53095 DMTABGTHGH4YC;C9CF9971-B67B-43B4-B272-4GF04FFF55D2;447A5575D1830B674FD0621DB7C53095 HTML5 Transcoder As previously described, the iViewer Project File is automatically transcoded to HTML5 and can then be called up with any HTML5-capable browser. Please note that different representations can arise following each deployment of the browser. We recommend use of the Safari Browser. No additional client license is necessary with HTML5. Please note that the representation under some circumstances may not always match 1:1 the representation in the iViewer. Special care should be taken with the texts being used that their fonts are also supported by the chosen browser. Also, gestures are only partly converted. Take care with lists that the inscribed size of elements ﬁts exactly. Otherwise, unwanted scroll bands could be generated. JavaScript, if deployed, is also completely supported, if it is supported by the browser engaged. As previously described, the appropriate Apps for mobile devices are made available. Care must be taken with mobile devices that the pixel sizes of the targeted system are adhered to exactly. Otherwise, the GUI cannot be presented. If several .gui ﬁles are held in the folder structure, these can be called up by means of selection from the Webbrowser.

5.2. Mini- Webserver 196 nomos Documentation, Release 1.1.73

The Webserver is accessible by calling up the IP Address of the corresponding nomos system.

5.2. Mini- Webserver 197 nomos Documentation, Release 1.1.73

5.3 Timer Support

The nomos system supports Timer and Calendar functions. Timers serve for, e.g., the cyclical callup of certain information. Calendars carry out processes defined in time (weekly cycle). Timers and calendars may be defined as running processes that can be changed, started or stopped. Structure of the Definitions Table:

Type: csv ﬁle Location: .\{projectPath}\misc\ Name: timer.csv Length: 256 timers possible Event: LOG Export: no License: no

The timer.csv is composed of 2 sections: [CONFIG]; General configuration of the interface parameter [TIMERS]; Definition of the Timer/Calendar entries Structure: • [CONFIG]; Section ACTIVE;YES „YES“ = active (default), „NO“ = inactive DEBUG;NO „YES“ generates a Log entry when a timer fires. „NO“, only the Start or Stop of a timer is logged (default).

• [TIMERS]; Section {Name};{Type};{time/s} o. {{Date-String}~{{Variance}};{Action};{Options} Explanation:

{Name} Designation of the timer {Type} Type of timer, possible values: INTERVAL cyclical timer fires at intervals of {time/s} IMMEDIATE as in the previous, but fires for the first time right at Start ONESHOT fires once after {time/s} CALENDAR weekly autotimer; the type can be abbreviated with three letters, CAL for CALENDAR , for example. {time/s} or interval in seconds ( max. 86,400s ((= 1day)) possible) is used with following {Type}: INTERVAL, IMMEDIATE, ONESHOT. or

5.3. Timer Support 198 nomos Documentation, Release 1.1.73

{Date-String}~{Variance} Date string for use of the {Type} = CALENDAR Examples of the date string are explained as follows. {Action} command sequence to be carried out .. {Options} further options in timer conﬁguration, currently possible: AUTOSTART starts the timer automatically upon starting the nomos systems. Examples of the Deﬁntions (simple Timer):

[TIMERS];IVT;INTERVAL;1; ;AUTOSTART starts the Timer IVT automatically upon System Start and carries out the iTunes commands at one-second intervals.

CLEARSCREEN;ONESHOT;5;; reserves the Timer CLEARSCREEN after the one-time command and carries out the corresponding command progression after five seconds. Example {Date-String} – possible content (CALENDAR): {nothing} fires every day at 0:00 hours {13} feuert jeden Tag um 13 Uhr {13:04} fires every day at 13:00 hours plus 4 minutes {13:04:05} fires every day at 13:00 hours, 4 minutes and 5 seconds {MONDAY} fires every Monday at 0:00 hours {WEDNESDAY,13:04} fires every Wednesday at 13:00 hours and 4 minutes {WEDNESDAY,MONDAY,13} fires every Wednesday and Monday at 13:00 hours {THURSDAY,13,29.11.} fires every Thursday at 13:00 hours -> When the weekday and the date are prescribed, the weekday takes precedence. Example {Date-String}~{Variance} - Random-Calendar-Timer, possible content (CALEN- DAR): The conventional CALENDAR timers can be augmented by a variance that can be chosen at will. In this way a new random time is created for every firing of the timer, which therefore makes it unpredictable. This makes sense, for example, with the presence simulations. The variance is directly added to the time in the timer string so that the designation of a time is required in this case. The defined time that is fixed then describes the targeted time and the variance measures the width of the deviation from the targeted time.

Syntax variants: {Date-String}~{Variance} ~{Seconds} ~{Minutes}:{Seconds} ~{Hours}:{Minutes}:{Seconds}

5.3. Timer Support 199 nomos Documentation, Release 1.1.73

01:00~30:00,SAT,SUN The time target is 01:00 hours on the weekend (Saturday and Sun- day); this is extended by a variance of 30 minutes. The timer fires sometime between 0:45 hours and 01:15 hours. SUN,MON,TUE,WED,THU,23:00~900 The time target is 23:00 hours on five different weekdays and this is augmented with a variance of 900 seconds (15 minutes). The timer therefore fires sometime between 22:52:30 hours and 23:07:30 hours. SAT,SUN,22:00~01:00:00 The time target is 22:00 hours on the weekend (Saturday and Sunday) and this is extended by a variance of 1 hour. The timer therefore fires sometime between 21:30 hours and 22:30 hours. The progression of clocked times, days of the week and dates in the date {Date-String} is irrelevant. The clocked time is always recognized as an isolated number (with or without „:“); the date is always at least a "." . {13,12.} fires every 12th of the month at 13:00 hours {24.12.,18} fires every Christmas Eve at 18:00 hours {13,25.12} fires at noon for Christmas Day dinner Weekdays can also be abbreviated with their three initial letters (required): MON,TUE,WED, etc. A CALENDAR timer, when its AUTOSTART option is not set, has to be started with START={Timername} , like all other timers. Example (CALENDAR Timer):

WAKEUP;CALENDAR;MON,TUE,WED,THU,FRI,07:00; ;AUTOSTART Starts the timer’s WAKEUP routine automatically upon system-start and executes iTunes command each working day at 07:00 hours.

BACHLAUF;CALENDAR;13:00;;AUTOSTART Starts the timer WAKEUP routine automatically upon system-start and executes the command every day at 13:00 hours.

Heating LR Night;CALENDAR;SAT,SUN,22:00~01:00:00; ;AUTOSTART; The time target is 22:00 hours; the variance amounts to 1 hour: The timer ﬁres sometime between 21:30 and 22:30 hours. Reports in the LOG: The actions of the timer can be followed in the Log. Expanded output is reported in the Log, if DEBUG;YES is set. Information on a timer that has been started.

Notiﬁcation on when the timer is set to ﬁre next.

5.3. Timer Support 200 nomos Documentation, Release 1.1.73

Information on the command execution of the timer (DEBUG;YES)

Timers can be manipulated dynamically during their running time. The following set of comands serves this purpose: There is a class of TIMER Commands with the following commands:

Command Argument Description {Name},{Timertype},{Value generates a new timer and inscribes it in the CREATE# or Date-String},{Timeraction} timer.csv deletes an existing timer (and halts it in any DELETE# {Name} case) removes AUTOSTART from the timer.csv DISABLE# {Name} and stops the Timer, if it has been running writes AUTOSTART behind an existing timer in ENABLE# {Name} the timer.csv and starts it, in case that had not yet happened LIST lists all active timers LISTALL lists all deﬁned timers by name RESET# {Name} sets the Timer {Name} back START# {Name}{Name} starts the Timer {Name} STOP# {Name}{Name} stops the Timer {Name} LIST# {Name} lists all active Timer {Name}

Names for timers {TimerName} can be employed at will. Examples: Generates a list of all active timers. If no timer is active, the list remains empty of entries.

> generates a CALENDAR timer, which says „Good Morning“ every morning at 07:00 hours. Timer type can also be abbreviated with its initial three letters. Timer actions designated with CREATE are no longer changed. Activates previously set timer and places it on AUTOSTART Correct Timer Deﬁnitions are conﬁrmed with the following Reply:

CREATE=|OK Existing timer cannot be changed. In order to change the timer, it must be deleted with the command DELETE= Command. If a CREATE= Command is carried out on a timer name that already exists, an Error message results:

5.3. Timer Support 201 nomos Documentation, Release 1.1.73

5.4 Counter Support

The nomos system also supports counters. Counters are handled like Sysvars, except that they are never stored. With every readout of a counter, the previous value is changed by one adjustable increment. For the manipulation of Counters, the following commands are available:

Command Argument Description initializes the Counter {Name}{,StartValue} {,Incre- {Name}.{StartValuet} and SETCOUNTER= ment} {Increment} are optional. Default is 0 for {StartValue} and 1 for {Increment} changes the size of the increment of an existing SETCOUNTERSTEP= {Name} {,Increment} Counter {Name}, 0 for {,Increment} stops the Counter. gives the current value of the Counter {Name}, GETCOUNTER= {Name} without changing it gives the current value of the Counter {Name}, GETALLCOUNTERS without changing it

In command sequences, the counter’s value can be referenced with [{Name}] (exactly as with the Sysvars, except that here the associated value of the counter is changed by the incremental step in tandem with this action.) Examples: generates the counter with the name [COUNT]. The counter begins with zero and advances by increments of 10. gives the current value of the counter with the name [COUNT]. Examples for the deployment of a Counter to transfer iTunes title as moving text in KNX Enter the following command in the init.myh : * causes the counter with the name ITC to be initialized at system-start. In the timer.csv then comes: ITT;INTERVAL;1;;AUTOSTART This entry defines a timer „ITT“ , which triggers a query, iTunes GETTITLE , at intervals of 1 second, for which the reported value returned is manipulated by the Parameter %c . The Parameter %c requires an index and a length. The index is written by the previously defined counter ([ITC]) and the length fixed with the value of 14 . The counter is activated automatically at system-start by the Autostart function. The following Event Server Definition now still has to be set up: .\events\lauftext.csv:

[CONFIG];; TRIGGERIP;INTERNAL;

5.4. Counter Support 202 nomos Documentation, Release 1.1.73

TRIGGERPORT;OUT TRIGGERMODE;ASCII; MATCHING;FULL;

[TRIGGERS];; GETTITLE{\%}=\*|;

The TRIGGER analyzes GETTITLE, namely the name of the currently playing iTunes title. The value that is matched is written to the KNX Address 1/5/5 . In the .esf type definition, of course, this has to be defined as ‘Character String’ (14 Byte) EIS 15. Thanks to the query, which is initiated by the second from the timer, the counter [ITC] rises continually by its incremental steps. Since no increment size was specified in the initialization of the counter, the default value, namely 1, has been assumed. The output string has been manipulated by the parameter %c . Only 14 characters are reported from a specified index. The index is described by the counter, which advances by 1 for every second of the query. The special characteristics of the parameter %c prevent an overflow. See the relevant description of the deployment of parameters in Formatting Options.

5.4. Counter Support 203 nomos Documentation, Release 1.1.73

5.5 Logic

The nomos system incorporates a powerful, integrated Logic Engine. The Logic Engine supports the universal Boolean expressions, such as NOT, AND, OR , as well as such comparable logic as EQUAL, UNEQUAL, GREATER, LESS, LESS-EQUAL, GREATER-EQUAL. The functions can be applied as desired. A multi- plicity of possible applications arises from this. A specialty of the Logic Engine is the manipulation of operands without regard to data type. This makes it possible to ﬁlter all information from the various protocols with the IN/OUT/BC channel and to process it directly into logical functions. Logic Engine can do the same to the Joins of the mremote.csv. A digital, analog or serial Join can be processed directly as OBJECT in this way. The same applies to system variables. Structure of the Deﬁnitions Table:

Type: csv ﬁle Location: .\{projectPath}\misc\ Name: logic.csv Length: 1,000 lines Event/Trigger: IN/OUT/BC - mremote - sysvars Export: - License: -

The logic.csv is composed of 3 sections:** [CONFIG]; general configuration of the interface parameter [OBJECTS]; definition of objects, which are needed as operands in logic processing. [LOGIC]; definition of the logical expressions. Structure: • [CONFIG];Section ACTIVE;YES Activate/deactivate the Logic Engine „YES“ (default)= active, „NO“ = inactive DEBUG;YES Extended LOG output „YES“ = active, „NO“ (default) = inactive • [OBJECTS];Section {Objectname};{Match};{StartValue};{Channel};ONCHANGE; Objects are defined herein, which are supposed to be validated for the Logic Engine. When JOINS or system variables are used, no further consideration need be given to these. Explanation:

{Objectname} Name of the object {Match} Match string to comprehend the value of the object {StartValue} Preliminary assignment of object value (optional, default: 0)

5.5. Logic 204 nomos Documentation, Release 1.1.73

{Channel} Analyser channels (IN/OUT/BC), on which matching is to occur (optional, default: IN,OUT,BC) ONCHANGE triggers the function (see below) only with value changes (optional)

• [LOGIC];Section {logic expression};{positive Action};{negative Action};{Triggerlist};ONCHANGE; Explanation:

{logic expression} linking of Objects, Sysvars and Constants {positive Action} Action that is to be carried out in the event of a logical “true” of the {logic expression}; objects can be inserted with [[ ]]. {negative Action} Action that is supposed to be carried out in case of a logical “false” of the {logic expression} ; objects can be inserted with [[ ]] . {Triggerlist} List of all Objects and Sysvars, which bump against the evaluation of the {logic expression} (optional, default: all) ONCHANGE Triggers the positive or negative Action only when the value of the logic expression has changed (true -> false or false -> true), optional. Operands of {logic expression}:

{Objectname} content of the Object {Objectname} {{D/S/A...}} content of a Join from the mremote.csv . {D512} for Digital Join 512 as example. [{Sysvarname}] content of the Sysvar {Sysvarname} "{Constants}" constant value logic connections:

! "NOT", logic negation, can appear before operands and parentheses | or || "OR", Operand a or Operand b is true & or && "AND", Operand a and Operand b are true equivalents:

= or == "EQUAL", Operand a is equal to Operand b != or <> "UNEQUAL", Operand a is not equal to Operand b > or >> "LARGER", Operand a is larger than Operand b (in terms of numerical value) < or << "SMALLER", Operand a is smaller than Operand b (in terms of numerical value) >= or => "LARGER-EQUAL", Operand a is larger than or equal to Operand b (in terms of numerical value) <= or =< "SMALLER-EQUAL", Operand a is smaller than or equal to Operand b (in terms of numerical value) computing rule:

5.5. Logic 205 nomos Documentation, Release 1.1.73

() the evaluation of content within parentheses takes precedence ﬂoating decimal-point numbers are also supported

Examples for the Definitions [OBJECT] Section: {Objectname};{Match};{StartValue};{Channel};ONCHANGE; MYVOL;\%|VOL=\*|;;BC,OUT;ONCHANGE; defines the Object MYVOL , which matches the content of the system volume from the OUT or BC channel. DP1;<1/1/6\%=\*>;;BC; defines the Object DP1 , which matches the content of the KNX group address 1/1/6 from the BC channel.

Examples of the deﬁnitions [LOGIC] Section: {logic expression};{positive Action};{negative Ac- tion};{Triggerlist};ONCHANGE;

(MYVOL > "50") & (MYVOL > [WANTEDVOLUME]) & ![DONTSAY];;;MYVOL;ONCHANGE; carries out action once, if the Object MYVOL changes its value and lands above the Value 50 as well as above the content of the Sysvar WANTEDVOLUME , and the Sysvar DONTSAY is logically false. Changes to [WANTEDVOLUME] or [DONTSAY] do not trigger the evaluation because MYVOL was explicitly deﬁned as trigger.

{D351} || {D352} || {D301} || D313});; ;;ONCHANGE; carries out the positive action, if one of the Digital Joins -- 351, 352, 301, 313 takes on the Value „1“ (OR). If all Digital Joins take on the Value „0“ , the negative action is carried out. The actions are only executed with a change from „0“ to „1“ or „1“ to „0“ , since the ONCHANGE option is set. Other notices: An OBJECT or a SYSVAR with the following content is logically “true”: {Value > 0}, TRUE,ON,YES. An OBJECT or a SYSVAR with the following content is logically “false”: 0,FALSE,OFF,NO. At the time of their evaluation, SYSVARS that are not deﬁned take on the Value "0" . Any desired OBJECTS and SYSVARS may be put in the trigger list, even if they do not appear in logical expression. The evaluation of the Joins is done „directly“, namely without regard to the mremote.csv, meaning that, for example, potentally deﬁned scalings of a-JOINS have no application. Matching takes place only on the values that are sent by the Daemon to the GUI. A differentiation among TOGGLE buttons, for example, can be made only in this way. Moreover, this indirectly allows AUTOFEEDBACK and DELAYFEEDBACK to affect them, when the logic is triggered. The remainder of the manipulation of the Joins (triggers, conditions, and so forth) is analogous to OBJECTS and SYSVARS.

5.5. Logic 206 nomos Documentation, Release 1.1.73

5.6 OSD Keyboard

The nomos system (Apple OS X version only) includes a virtual keyboard. This OSD Keyboard is a component of the nomos GUI. The OSD Keyboard is outstandingly suitable for systems with Touchscreen. The width of the keyboard always measures 50% of the actual width of the viewing screen; the proportions of the keyboard always stay constant, independently of the relationship to the size of the displayed image. When the mouse’s cursor is outside the keyboard, it is about 70% transparent. The keyboard can be clicked up anywhere on the background and dragged over the screen. The keyboard is is always the uppermost window. The application sent with Key Events is always that which was in focus either at the callup of the keyboard or was there as the mouse’s cursor was moved across the keyboard.

Double clicking on the upper tenth (above the F Key) of the keyboard makes the keyboard disappear: Limi- tation: The Fn Key does not yet function. For control of the OSD Keyboard, the following commands are available:

SHOWKEYBOARD Superimposes the input facilitator (Keyboard) HIDEKEYBOARD Occults the input facilitator (Keyboard)

Examples: opens the virtual keyboard on an Apple OSX system closes the keyboard again on the Apple OSX system.

5.6. OSD Keyboard 207 nomos Documentation, Release 1.1.73

5.7 System Recognition in the Network - ZeroConf

The nomos system features automatic system recognition in the network (Zero-conﬁguration networking - Zeroconf). It recognizes independently and mutually all nomos and related OEM versions. A list of the IPs of all systems found can be called up with the following command: callup of the available nomos systems in the network

possible answer: GETSYSTEMLIST=192.168.50.60 | 192.168.50.61 | 192.168.50.55 | OK Furthermore, one can load down without charge on one’s iPhone/iPad the App ROZeroConf. The nomos system makes two services available for this App. _rmtsysctrl lists all running daemons (including their OEM names, serial numbers) and shared command servers in the network. _rmtsysinfo , by contrast, provides MAC address, IP, serial number, name and version of the Box, even when no valid license is held. A DHCP server is needed in the network for the initial operation of nomos Boxes. The assigned IP is obtained either from the Log of the DHCP server or with the ZeroConf protocol. The ZeroConf App is thereby extremely helpful for putting nomos Boxes into operation for the ﬁrst time.

5.7. System Recognition in the Network - ZeroConf 208 nomos Documentation, Release 1.1.73

Depiction of the ZeroConf browser When found, systems also appear in the LOG with names and IP addresses. For example, a report like the one below appears in the LOG. The report is sent automatically to all systems present after each start of a system:

Allowing the LOG output to be displayed after a system start (Initial LOG) is recommended.

5.7. System Recognition in the Network - ZeroConf 209 nomos Documentation, Release 1.1.73

All available systems are listed under system: remote system.

5.7. System Recognition in the Network - ZeroConf 210 nomos Documentation, Release 1.1.73

5.8 VPN Access

The nomos system contains an integrated Support Interface (Open VPN). The user can enable access by command or with dialog (Wizard versions). Once access has been cleared, the nomos Support Team is positioned to reach the box through a VPN channel. This assures that only the nomos system can be reached exclusively in your network structure. The VPV function is preinstalled on the nomos Box versions. A corresponding VPN package is available for the Apple OS X version. This VPN package for Apple OS X is based on the Tunnelblick Application (http://www.tunnelblick.net). This application is preconfigured accordingly and modified for nomos use. An active VPN connection can be recognized from the tunnel symbol on the upper right-hand side of the system bar, when the symbol is showing a green light beam. A right-click and then “Tunnelblick beenden” severs the VPN connection; a double click on the Tunnelblick Application in the program folder starts it. To make control through the nomos system possible, the application may not be renamed or repositioned! Additionally, no manual updates of the application should be undertaken, since a special version of the application would be needed. As with the nomos Box versions, control is exercised with the commands: initiates the VPN connection ends the VPN connection Please make sure that an active VPN connection also remains available after a restart of the system. Should you wish to prevent VPN access for the duration, you would have to shut off the service. If the VPN connection is open, the assigned VPN IP can be called up on command. The VPN IP address is issued as fixed. This is done preemptively so that the VPN IP address is bound to the serial number of the nomos system. The IP address as issued then endures for a longer period. delivers the VPN IP, if a VPN connection exists

possible answering sequence reply sequence: GETVPNIP=10.72.0.26|OK You must report the VPN IP Address to the Support Team. With nomos Box versions, you also receive this information through the Basis Conﬁguration in the ﬁeld of VPN/Support. Depending upon the version, the clarifying depictions may look different.

5.8. VPN Access 211 nomos Documentation, Release 1.1.73

The nomos Support Team retains the exclusive possibility of VPN access at the moment. In the future there will be a portal through which the user registers his system and can then also gain access to this interface.

5.8. VPN Access 212 CHAPTER 6

TABLE of key codes SYSTEM EVENTS

APPLESCRIPT German Apple USB Keyboard, later also applicable to other keyboards (information provided without guarantee):

key code 1 = “s”! key code 75 = NUM [/] key code 2 = “d” key code 76 = NUM [Enter] key code 3 = “f” key code 77 = [ArrowUp] key code 4 = “h” key code 78 = NUM [-] key code 5 = “g” key code 79 key code 6 = “y” key code 80 key code 7 = “x” key code 81 = NUM [=] key code 8 = “c” key code 82 = NUM [0] key code 9 = “v” key code 83 = NUM [1] key code 10 = “^” key code 84 = NUM [2] key code 11 = “b” key code 85 = NUM [3] key code 12 = “q” key code 86 = NUM [4] key code 13 = “w” key code 87 = NUM [5] key code 14 = “e” key code 88 = NUM [6] key code 15 = “r” key code 89 = NUM [7] key code 16 = “z” key code 90 key code 17 = “t” key code 91 = NUM [8] key code 18 = “1” key code 92 = NUM [9] key code 19 = “2” key code 93 key code 20 = “3” key code 94 key code 21 = “4” key code 95 key code 22 = “6” key code 96 = [F 5] key code 23 = “5” key code 97 = [F 6] key code 24 = ” “ key code 98 = [F 7] key code 25 = “9” key code 99 = [F 3] key code 26 = “7” key code 101 = [F 9] key code 27 = “ß” key code 100 = [F 8] key code 28 = “8” key code 102 key code 29 = “0” key code 103 = [F11] key code 30 = “+” key code 104

213 nomos Documentation, Release 1.1.73

key code 31 = “o” key code 105 = [F13] key code 32 = “u” key code 106 = [F16] key code 33 = “ü” key code 107 = [F14] key code 34 = “i” key code 108 key code 35 = “p” key code 109 = [F10] key code 36 = [Return] key code 110 key code 37 = “l” key code 111 = [F12] key code 38 = “j” key code 112 key code 39 = “ä” key code 113 = [F15] key code 40 = “k” key code 114 = [Help] key code 41 = “ö” key code 115 = [PgUp] key code 42 = “#” key code 116 = [Home] key code 43 = ”,” key code 117 = [Fwd-Del] key code 44 = “-“ key code 118 = [F 4] key code 45 = “n” key code 119 = [PgDwn] key code 46 = “m” key code 120 = [F 2] key code 47 = ”.” key code 121 = [End] key code 48 = [Tab key code 122 = [F 1] key code 49 = [Space] key code 123 = [ArrowLeft] key code 50 = “<” key code 124 = [ArrowRight] key code 51 = [Bkw-Del] key code 125 = [ArrowDown] key code 52 = [Return] key code 126 = [ArrowUp] key code 55 = [Command] key code 127 key code 54 = [Command] key code 128 = “a” key code 53 = [Escape] esc key code 54 = [Command] (starting with 129 begins again from the start: 129 = “s”, 130 = d”, etc. key code 55 = [Command] key code 56 = [Shift] key code 57 = [ShiftLock] key code 58 = [Alt] key code 59 = [Ctrl] ctrl key code 60 = [Shift] key code 61 = [Alt] key code 62 = [Ctrl] ctrl key code 64 key code 64 key code 67 = NUM [*] key code 68 key code 69 = NUM [+] key code 70 = [ArrowLeft] key code 71 = NUM [X] key code 72 = [ArrowDown] key code 73 key code 74

214 CHAPTER 7

Workarounds, Previews

We understand under “workarounds” those possibilities that are still undergoing trials. We do not wish to withhold these functions from you. Instead, we offer them to you so that you can test them for yourself, and we will be grateful for your feedback on how they worked out. Please be aware that no claim may arise from the evaluation of these functions. It could also happen that we later decide not to pursue the described possibilities.

7.1 DVD Copy Window

The copying function anticipates in the gui folder a ﬁle, DVDCopy.csv , with the following content:

[CONFIG];

ACTIVE;YES activates the copier function (default: NO ) PATH;{path to the DVD collection folder} The path must already be present; take care with the correct naming of the folders. The folder „FilmS“ that shows in the „Finder“ is actually called „Movies“. An example of the local path of the standard folder structure would be: /Users/mmh/Movies How the function works: When a disk is inserted, it is ﬁrst checked to determine whether there is a VIDEO_TS folder on the disk. If there is, further scrutiny then determines whether a folder with the same name exists already in PATH. If not, a small window with the DVD name opens at top center. If this window is disregarded, it closes automatically again after 10 seconds. One clicks on “Copy”, starts the copier routine, the progress monitoring bar enlarges and ﬁnally the DVD is ejected. If one clicks (regardless of when) on “Abort”, the copying procedure is broken off, the incomplete target folder that had been created is deleted and the DVD is ejected. The function draws on the internal copier function of Apple OSX. In the future a path to a Shellscript can also be given. Other copier programs can also be called up with this and eventually the necessary parameters transferred. Copier protection: This function prevents any protected media from being copied!

215 nomos Documentation, Release 1.1.73

7.2 iTunes Remote

With the new iPod Touch and the new generation of iPhone devices, Apple has opened the „gate“ for native software applications of third parties. Apple itself has made available the software „Remote“ (free for loading from the iTunes application store). Apple Remote makes possible comfortable steering of iTunes and AppleTV with recourse to AirTunes loudspeakers from these same devices. In this chapter we will show you how, as a user of nomos, you can also take advantage of these additional control reﬁnements and make appropriate use of the new potentialities. Since nomos does not have recourse directly to the Remote application, we make use of the typical capabil- ities of the event server. The PLAYERSTATUS of the iTunes application is monitored with this. As soon as iTunes is playing over Remote, locally or with other applications, nomos reports the status through the broadcast port. GETPLAYERSTATE=PLAYING|OK This report can be evaluated with the following EventServer Definition:

[CONFIG];

TRIGGERIP;192.168.50.55 local IP address TRIGGERPORT;1038 local broadcast port TRIGGERMODE;ASCII receives an ASCII code

[TRIGGERS]; GETPLAYERSTATE=*|;iTunesRemoteEvent.myh;ONCHANGE The trigger definition in detail signifies: GETPLAYERSTATE=*|; The entry „*“ parses the value of an incoming chain of characters between ... GETPLAYERSTATE=“ and the end-sign „|“. The arrival of the above-mentioned Status String would fulfill the condition and the Match would be „PLAYING“ iTunesRemoteEvent.myh is the name of the Script file that would be carried out if the condition was met. In this case, totally independent at first from the content of the „matched“ strings. ONCHANGE In order for the Script to be carried out only when the match has also changed while the condition was met, the Parameter ONCHANGE is employed. As described in the chapter on the EventServer, the Match can be deployed as transfer parameter [ARG] for calling up the Script. Meaning of the Scriptfile: For this reason we have structured the Script to be called up in a way that should clarify for you the functionality as follows.

The Script iTunesRemoteEvent.myh serves in this case to trigger another Script with the callup of a Parameter. Since the Match with the value „PLAYING“ is fulﬁlled, the callup of the Script ﬁle results, when it is there, in iTunesRemoteEvent_PLAYING.myh The Script iTunesRemoteEvent_PLAYING.myh contains in this way the actual command sequence that is supposed to be executed when the iTUNES status has changed to PLAYING.

7.2. iTunes Remote 216 nomos Documentation, Release 1.1.73

... as an example. Naturally, for every status output, a corresponding SCRIPT with appropriate functions can be laid on.

7.2. iTunes Remote 217 nomos Documentation, Release 1.1.73

7.3 Use of the Squeezebox as IR receiver for controlling nomos

The Logitech Squeezebox comes with an infrared receiver. This can be exploited to control remotely the nomos system or other devices with, for example, the Squeezebox remote-control device or the small Apple IR-Remote! the application is installed as follows: In the Squeeze-center under settings -> Plugins -> xPL interface, set the “infrared processing” on “Raw” and play. The xPL.csv for the corresponding Squeezebox is extended by the following lines:

[SCHEMA=osd.basic]; OSDWRITE;COMMAND=write OSDCLEAR;COMMAND=clear OSDCLEAR;COMMAND=clear OSDRELEASE;COMMAND=release OSDTEXT;TEXT=\# OSDROW;ROW=\# OSDCOLUMN;COLUMN=\# OSDDELAY;DELAY=\# [WATCH=remote.basic]; keys;REMOTE_KEY

Set up a .csv for the Eventserver, which the infrared command-set translates into nomos commands (here for the Apple Remote):

[CONFIG]; TRIGGERIP;INTERNAL TRIGGERPORT;BROADCAST TRIGGERMODE;ASCII [TRIGGERS]; REMOTE_KEY=77e150bf; REMOTE_KEY=77e130bf; REMOTE_KEY=77e160bf; REMOTE_KEY=77e190bf; REMOTE_KEY=77e1c0bf; REMOTE_KEY=77e1a0bf; GETCH- NAME=\*|; |VOL=\*|;

The Class must be adjusted as needed, of course, depening upon how the Squeezebox deﬁnition was named.

7.3. Use of the Squeezebox as IR receiver for controlling nomos 218 nomos Documentation, Release 1.1.73

Following a New Start of nomos, direct the Apple Remote at the Squeezebox and control EyeTV as network through infrared:

Left/right switch programs high/lower louder/quieter play TV on menu TV off

As feedback, the transmitter or sound volume will display for 10 seconds - actually rather senseless, but quite useful to show that it is working in both directions.

7.3. Use of the Squeezebox as IR receiver for controlling nomos 219 nomos Documentation, Release 1.1.73

7.4 Useful Shortcuts and Keyboard Commands

Always impressive is the number of hidden and unknown cryptic keys, key combinations or shortcuts there are in Apple OS X and the new SnowLeopard that can be useful for controlling applications without resort to the mouse or the touchpad. There follows below a listing of all the possible shortcuts and key combinations in OS X/Snow Leopard and the software installed for it, which can make the daily work routine on your Apple computer proceed even more efﬁciently. (source: iFAQs.de ) iFAQs.de - Shortcuts for the System Start of OS X/Snow Leopard:

Starts the Open Firmware Console at System [ALT]+[CMD]+O+F Start. The computer first tries to boot from CD-ROM C drive The computer first tries to boot from the internal D harddisk. [ALT]+[CMD]+P+R deletes the Paramter RAM. Backspace circumvents the current start vol- [SHIFT]+[ALT]+[CMD] ume. opens on new computer the dialog for selection [ALT] of a start volume [ALT] select start volume upon system start [CMD]+V starts the Verbose Mode left mouse clicker ejects CD upon system start T start computer in Target Mode circumvents the current start volume and seeks [SHIFT]+[ALT]+[CMD]+[Del] an alternative start volume. N Automatic search for a bootable network drive [SHIFT] System start in the Safe Boot Mode [CMD]+S starts the Single User Mode D starts partition from the first hard disk X starts OS X from the active start volume

iFAQs.de - Shortcuts for making screenshots:

[SHIFT]+[CMD]+3 Screenshot of the whole screen Screenshot is secured automatically in the in- [SHIFT]+[CTRL]+[CMD]+3 terim storage. Selection with target symbol the area to be pho- [SHIFT]+[CMD]+4 tographed. [SHIFT]+[CMD]+4+Leertaste The camera photographs the area shown (blank spacing key/bar) [SHIFT]+[CMD]+F4 The current window is photographed

7.4. Useful Shortcuts and Keyboard Commands 220 nomos Documentation, Release 1.1.73

7.5 Special Characters (Mac/Win/VM-Ware)

Special characters that are not found on the keyboard are sometimes needed for the nomos protocol. Also, when using a virtual machine, the key assignments in the keyboard layout, do not conform to those of the Apple keyboard layout. We show the most important peculiarities of the keyboard layout in the following:

Characters OS X WIN @ [ALT]+L [ALT]+Q / [SHIFT]+7 [SHIFT]+7 \ [ALT]+[SHIFT]+7 [ALT]+ß [ [ALT]+5 [ALT]+8 ] [ALT]+6 [ALT]+9 | [ALT]+7 [ALT]+< { [ALT]+8 [ALT]+7 } [ALT]+9 [ALT]+0

7.5. Special Characters (Mac/Win/VM-Ware) 221 CHAPTER 8

nomos Cloud API

The nomos Cloud API gives developers or external services access to the nomos IoT automation platform. We offer basically two connection types within the Cloud. One is the commonly used REST Service; the other is the advanced “REALTIME” version based on socket.io. The REST Service sufﬁces for most applications and is ideally suited for triggering actions and receiving feedback. For more comprehensive applications we recommend the REALTIME API with its unique possibility to register a broad range of listener responses. Sign up at: https://cloudapi.nomos-system.com/apirequest Minimum Requirements • Daemon 1.1.74 • HTML5 3.0.50

8.1 API Doku General

Developers or external services can gain access to nomos-controlled systems by means of the nomos Cloud API. OAuth 2.0 authentication makes sure that these clients obtain access only with licensed users and their systems.

222 nomos Documentation, Release 1.1.73

The nomos Cloud API offers basically two different interfaces: the commonly used REST Service and a „REALTIME“ variant based on socket.io. The REST Service sufﬁces for most applications and is best suited for giving and executing commands. Current status and characteristics can also be queried.

For actions in which timing is crucial or in cases requiring a reaction to certain changes in value or status,

8.1. API Doku General 223 nomos Documentation, Release 1.1.73 the „REALTIME“ interface is your choice. Explicit descriptions and details for use of these interfaces now follow. OAuth 2.0 Authentication The nomos Cloud API supports the authorization framework OAuth 2.0. This enables external services to request access to a user’s account and systems without having to know his log-in credentials. In order to use the OAuth interface, a client ID and a client code are required. If you lack either the client ID or the client code, you may request access here: https://cloudapi.nomos-system.com/apirequest Standard procedure You need to execute the following five steps to create an API request: 1. Request access to the nomos account 2. nomos redirects the user to the authorization page 3. Request an access token 4. Receive the access token 5. API Request, see REST or REAL TIME API section 1. Request access to the user account GET https://cloudapi.nomos-system.com/oauth/authorise Parameter client_id Required string - The client id you have received from nomos redirect_uri Required string - The user will be redirect to this url after the authorization. The user has to login in this step. 2. nomos redirects the user to the authorization page If the user confirms the authorization request, he will be redirected back to the previously defined „redi- rect_uri“. nomos will add the GET parameter „code“ to this „redirect_uri“. This code is only valid for a few seconds and can be used to request an access token (see step 3). 3. Request an access token You can request an access token by using the code you have received during step 2. POST https://cloudapi.nomos-system.com/oauth/token Parameter client_id Required string - The client id you have received from nomos redirect_uri Required string - The same redirect uri as in step 1 client_secret Required string - The client secret you have received from nomos code Required string - The code you have received during step 2. grant_type=authorization_code Required string

8.1. API Doku General 224 nomos Documentation, Release 1.1.73

4. Receive the access token Once you have requested the access token you will receive the following JSON response:

{ „token_type": "bearer", „access_token": "fd4889d3d6d329b67d209ec5834d7e04a17a8ab0", „expires_in": 3600, „refresh_token": "a0c88b520633d5ec5a39812da13377fb26426eb0" }

The access token is valid for a limited time. The lifetime of the token can be learned from the value of expires_in. In this case, the access token is valid for 14400 seconds -> 4 hours. The value refresh_token (valid for 2 weeks) can be used to request a new access token. Refresh the access token by using the refresh token If the access token has expired, a new access token can be acquired by using the refresh token. POST https://cloudapi.nomos-system.com/oauth/refresh_token Parameter client_id Required string - The client id you have received from nomos client_secret Required string - The client secret you have received from nomos refresh_token Required string - The refresh token you have received during step 4 Response You will receive the same response as in step 4. Please note that the values „access_token“ and „refresh_token“ are different. Once you have requested a new access token, the old refresh token will no longer be valid.

{ "access_token": "c0d8b09a3d6867d31cbba64a3d5574a69eda9238", "expires_in": 3600, "token_type": "bearer", "refresh_token": "461690a37d06d0b994b008805ac1df025bbe72d8" }

REST API Any request has the following structure: https://cloudapi.nomos-system.com/control/ + resource This would result in the following url to fetch user informations: GET https://cloudapi.nomos- system.com/control/user The access token you have received in OAuth Step 4 must be used in the Header Authorization. Please use a header like this: | Authorization: Bearer %access_token%. In addition you must add an Accept header to the call. This results in the following headers:

Accept: application/json, text/javascript Authorization: Bearer a0c88b520633d5ec5a39812da13377fb26426eb0

8.1. API Doku General 225 nomos Documentation, Release 1.1.73

HTTP-Headers Accept „application/json, text/javascript“ or „application/xml, text/xml“ The response format you expect from the service. Authorization Bearer %access_token% Access Token from the OAuth 2.0 authorization. HTTP-Verbs GET requests a resource from the server. POST execute a resource HTTP-Codes

Code Description 200 Request OK 304 The resource has not been changed 401 The access token is invalid 403 You do not possess the required rights to access this resource. 404 The resource could not be found / is unknown. 500 An unexpected condition was encountered 503 The server is not available (maintenance work).

Callbacks (JSON-P) Every request accepts the GET parameter „?callback“. Callbacks are often used to avoid „cross domain“ problems. Please note that the content type of the response is always „application/javascript“. For more informations see https://en.wikipedia.org/wiki/JSONP Hints You have to URL encode special parameter names if necessary. For example with a KNX address which has „/„ and blanks in it: > system/NXS12345678/class/knx/value/1%2F2%2F3-Test%20Address Available API Ressources see Testsuite section REALTIME API Unlike with REST, connection to the nomos Cloud API is made here through socket.io (http://socket.io). Once established, the connection remains in place. At this stage various functions or commands are available for retrieving or transmitting information. The main advantage, however, lies the „Listener“ functionality, which will be described below.

8.1. API Doku General 226 nomos Documentation, Release 1.1.73

Important: only socket.io compatible; use through native WebSocket is not possible! Making the durable connection The socket.io URL is: https://cloudapi.nomos-system.com/control Query Parameter client Required string - The client id you have received from nomos access_token Required string - The access token you have received in OAuth step 4 Example with jQuery: var socket = io.connect(‘https://cloudapi.nomos-system.com/control‘, {query: $.param({access_token: “a0c88b520633d5ec5a39812da13377fb26426eb0 “, client: “%CLIENT_ID%“})}); Example without jQuery: var socket = io.connect(‘https://cloudapi.nomos-system.com/control‘, {query: “access_token=a0c88b520633d5ec5a39812da13377fb26426eb0&client=%CLIENT_ID%“}); Requests Example Call to fetch user informations: socket.emit(“getUser“, {}, function(data) { alert(data); });

Listeners For the Listener functionality, the following must be done only once: socket.on('listenerEvent', function (e) { alert(e); });

A „Listener“ can now be registered with the function „registerListener“. Example for obtaining notiﬁcations of title changes for iTunes: socket.emit(“registerListener“, { "sid": „%SYSTEMID%“, "class": "itunes", "value": "title"}, function(data) {} });

The Event Listener „listenerEvent“ will now be called up automatically upon changes in titles and the data can then be further modiﬁed. Furthermore, the functions „unregisterListener“ and „getRegisteredListener“ are available. Available API Ressources see Testsuite section Testsuite The so-called „Testsuite“ is available to developers desiring a more comprehensive grasp of the procedures.

8.1. API Doku General 227 nomos Documentation, Release 1.1.73

This can be reached under: https://cloudapi.nomos-system.com/testsuite Testsuite offers not just an overview of the available commands and functions but also permits them to be tried out directly in use. Notice When calling up several command chains of one class simultaneously, it is best to make use of the „RAW“ commands. Downloads: Library for PHP https://github.com/nomos-system/cloudapi-lib-php Library for JavaScript https://github.com/nomos-system/cloudapi-lib-js

8.2 API Befehlssatz

Stand 25.11.2014

Beschreibung REST REALTIME/WEBSOCKET ALLGEMEIN liefert eine Liste der Systeme GET /system getSystems() liefert ein bestimmtes System GET /system/SYSID getSystem({sid: SYSID}) liefert den Online Status eines GET /system/SYSID/online getSystemOnline({sid: SYSID}) bestimmten Systems liefert die Metadaten eines bes- GET /system/SYSID/meta getSystemMeta({sid: SYSID}) timmten Systems liefert User Account Details GET /user getUser() KLASSEN UND DEVICES liefert eine Liste der De- GET /system/SYSID/class getClasses({sid: SYSID}) vices/Klassen liefert alle aktuellen Werte einer GET /system/SYSID/class/ getClassValues({sid: SYSID, class: CLASS}) Klasse CLASS/value liefert bestimmten Wert einer GET /system/SYSID/class/ getClassValue({sid: SYSID, class: CLASS, Klasse CLASS/value/VALUE value: VALUE}) liefert alle verfügbaren reg- GET /system/SYSID/class/ getClassCommands({sid: SYSID, class: ulären Befehle einer Klasse CLASS/command CLASS}) liefert alle verfügbaren SET Be- GET /system/SYSID/class/ getClassSetProperties({sid: SYSID, class: fehle einer Klasse CLASS/set CLASS}) liefert alle verfügbaren GET GET /system/SYSID/class/ getClassGetProperties({sid: SYSID, class: Befehle einer Klasse CLASS/get CLASS}) execRAW({sid: SYSID, raw: {“version”:1,”method”:”command”,”class”: Aufruf JSON RAW Befehl POST /system/SYSID/raw “CLASS”,”command”:[{“name”: “COM- MANDNAME”, “value”:”VALUE”}]}}) POST /system/SYSID/class/ Aufruf eines bestimmten reg- execClassCommand({sid: SYSID, class: CLASS/command/ COM- ulären Klassen Befehls samt CLASS, command: COMMANDNAME, MANDNAME (PARAME- Parametern param: PARAMETERS}) TERS) Aufruf eines bestimmten SET POST /system/SYSID/class/ execClassSetCommand({sid: SYSID, class: Klassen Befehls samt Parame- CLASS/set/PROPERTYNAME CLASS, property: PROPERTYNAME, param: tern (PARAMETERS) PARAMETERS})

8.2. API Befehlssatz 228 nomos Documentation, Release 1.1.73

Beschreibung REST REALTIME/WEBSOCKET Aufruf eines bestimmten GET POST /system/SYSID/class/ execClassGetCommand({sid: SYSID, class: Klassen Befehls samt Parame- CLASS/get/PROPERTYNAME CLASS, property: PROPERTYNAME, param: tern (PARAMETERS) PARAMETERS}) REALTIME EXCLUSIVE BEFEHLE registerListener({sid: „SYSID“, class: Realtime Listener registrieren —— „CLASS“, value: “VALUE”}) Realtime Listener deregistri- unregisterListener({sid: „SYSID“, class: —— eren „CLASS“, value: “VALUE”}) liefert Liste der registrierten —— getRegisteredListener() Listener „listenerEvent“ wird automa- tisch aufgerufen bei Wertän- —— EVENT: listenerEvent(DATA) derungen

8.2. API Befehlssatz 229 CHAPTER 9

Legal Advisory

The program material contained in this software and in this handbook is not bound by any obligation or guarantee of any kind. nomos system AG, therefore, assumes neither responsibility nor liability of any nature that might otherwise be construed to arise from the use of the software, the handbook, or any portions thereof in any way whatsoever. This work, including all its parts, is protected by copyright. Any exploitation of it that transcends the narrow bounds of copyright law is prohibited and actionable unless expressly authorized by nomos system AG. This applies especially to reproduction, translation, microfilming as well as storage and processing in electronic systems. No claim of any sort whatsoever arises at the time the announced functionalities or their announced refine- ments become available, unless or until they are officially cleared for use by nomos system AG.

230 CHAPTER 10

Version History

coming soon, please consult our Forum: http://forum.nomos-system.com/

231 CHAPTER 11

Attachments (templates)

The configuration files have been explained in detail in the earlier chapters. There follows here copied templates for the various files, with all available parameters attached. Included as well are helpful commentary texts.

11.1 {commandserver}.csv

File structure and possible parameters of the CommandServer Definitions. The name of the file defines the class name. Location: ./[Project]/addons/

// System name, manufacturer, TYP

// Interface Parameter // creator

[CONFIG] ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Extended protocol active {“YES”/”NO” - Default} SERVERIP;192.168.1.200; // remote {IP} or {“LOCAL”} SERVERPORT;6000; // remote Port or serial Interface SERVERPROTOCOL;UDP; / {“UDP”}/{“TCP”}/{“HTTP”}/{“HTTPS”}/{“AUTO”}/{“SERIAL”} SERVERMODE;ASCII; / {“ASCII”}/{“HEX”} SERVERTIMEOUT_IN_MS;1000; // Timeout {0..3600} ms or {“NONE”}

--- Extended (Optional)---

// MATCHING; // Matching mode: {“FULL”}/{“NORMAL”} // EXPORT; // Clearance of the CommandServers (sharing option) // CLIENTIP; // further Client IPs to which replies are sent // CLIENTPORT; // Port of the Client // LOCALPORT; // Local Socket Port // SERVERTIMEOUT; // like TIMEOUT_IN_MS except {0...3600} sec. or {“NONE”} // SERVERTYPE; // Checksums calculation

232 nomos Documentation, Release 1.1.73

// STARTUPCMD; // Command at start or to make connection automatically // HEARTBEATCMD; // {HeartbeatCMD};{Heartbeatinterval} in s. Default = 60s // {“YES” - Default/”NO”} automatically reconnecting after connection // RECONNECT; is broken off. // // CMDPREFIX; // Prefix for each command // CMDSUFFIX; // Suffix for each command // SEQUENCEPREFIX; // Prefix for each command sequence // SEQUENCESUFFIX; // Suffix for each command sequence // // STARTDELIMITER; // Delimiter/Separation sign at the beginning of the Match sequence // ENDDELIMITER; // Delimiter/Separation sign at the end of the Match sequence // MAPPREFIX; // Prefix for each Match // MAPSUFFIX; // Suffix for each Match // // SPACING; // Command delay (Sequences) {t in ms} // // USERNAME; // whenever authentication required - User name // PASSWORD; // whenever authentication is necessary - Password

[COMMANDS];

// Structure

// {mmh-Command};{Protocol sequence};{Different Command Timeout};{Parameter}

[MAPPINGS];

// structure:

// {Protocol-Match};{mmh-Name};{local Action};ONCHANGE;{Match-Condition}

11.1. {commandserver}.csv 233 nomos Documentation, Release 1.1.73

11.2 {buttons}.csv (Mac only)

File structure and possible parameters of the button definitions (Mac only). The name of the file defines the name of the button bar. Location: ./[Project]/gui/ // creator

[CONFIG] ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Extended protocol active {“YES”/”NO” - Default} TIMEOUT;5; // time until bar closes automatically POSITION;BUTTOM; // position of the bar {LEFT/RIGHT/TOP/BOTTOM (default)} SIZE;AUTO; // elevation of the bar in pixels AUTO=default CLOSEBUTTON;YES; / bar closable (with POSITION;BUTTOM only) HUD;YES; // HUD mode (only with POSITION;BUTTOM) TRANS;0.95; // transparency of button bar {0.1...1.0}(default: 0.8) RED;0.16; / red portion of the button bar GREEN;0.16; // green portion of the button bar BLUE;0.16; // blue portion of the button bar TEXTRED;0.16; // red portion of the button text TEXTGREEN;0.16; // green portion of the button text TEXTBLUE;0.16; // blue portion of the button text // TEXTBACKGROUNDRED; / red part of the button-text background // TEXTBACKGROUNDGREEN; // green part of the button-text background // TEXTBACKGROUNDBLUE; / blue portion of the button-text background // TEXTSIZE; // size of the characters in the button text (default: dynamic) MAGE;SCALE; // {SCALE (default) /CENTER/TOP/BOTTOM/LEFT/RIGHT}

[BUTTONS];

// assignments:

// {Label1};{Action1};{Buttontype};{Action2};{Graﬁk1};{Label2};{Graﬁk2}

11.2. {buttons}.csv (Mac only) 234 nomos Documentation, Release 1.1.73

11.3 webserver.csv

File structure and possible parameters of the Webserver definitions. The fixed file name is mandatory. Location: ./[Project]/misc/

// mini Webserver

// Notice: TV station logotypes have to be entered under ../misc/web/tv_{Channel name}.jpg(png).

// {Channel name} is identical to the name of the station from eyeTV.

//‘

// eyeTV URL’s:

// http://{IP:PORT}/tv_current.jpg(png)

// http://{IP:PORT}/tv_{Channel name}.jpg(png)

// iTunes URL’s:

// http://{IP:PORT}/itunes_current.jpg(png)

// http://{IP:PORT}/iTunes_ID_{ID}.jpg(png)

// http://{IP:PORT}/iTunes_album_{Ablum Name}.jpg(png)

// AppleTV (remote) URL’s:

// http://{IP:PORT}/[ATV CLASS]_current.jpg(png)

// SONOS URL’s:

// http://{IP:PORT}/[SONOS CLASS]_current.jpg(png)

// DVD Player URL’s:

// requires "preview.jpg" in the DVD folder

// http://{IP:PORT}/dvd_current.jpg(png)

// http://{IP:PORT}/dvd_{dvd title}.jpg(png)

// General information:

// - URL is not case senstive

// - dummy ﬁle support

11.3. webserver.csv 235 nomos Documentation, Release 1.1.73

// ../misc/web/tv_dummy.jpg(png) - for eyeTV

// ../misc/web/itunes_dummy.jpg(png) - for iTunes

// ../misc/web/dvd_dummy.jpg(png) - for DVD Player //

[CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Extended protocol active {“YES”/”NO” - Default} PORT;1234; // Webserver Port GUIPORT;1235; // GUI download Port or PORT +1 // DVD_COVER; // Assigns the DVD cover names (Default: preview.jpg) // DVD_PATH; // Deﬁnition with local URL {Users/[PROFILE]/Movies/}

[ALIASES];

//{Aliasname};{URL};

11.3. webserver.csv 236 nomos Documentation, Release 1.1.73

11.4 sysvars.csv

File structure of the sysvar.csv. File name is ﬁxed and mandatory. The content of the variables can be changed during running time. Location: ./[Project]/misc/ // reserved for the system and generates variables automatically:

// [SYSTEM_IP] - current IP // [SCREEN_X] - current x-resolution of the viewing screen // [SCREEN_Y] - current y-resolution of the screen // [BUTTON_SIZE] - current elevation of the button bar // [HOMEDIR] - current index // [PROFILE] - current proﬁle name (short name) // [PROJECT] - current project path // [TIME] - current time in the KNX EIS3 format // [DATE] - current date in the KNX EIS3 dormat / [OEM_NAME] - name of the OEM version // [SYSTEM_SERIAL] - serial number of the current hardware // [SYSTEM_MAC] - MAC address of the network interface // // [ARG] - internal interim storage argument buffer // [GARG] - internal interim storage argument buffer (global) //

//*****************************************************************************

// Proﬁle speciﬁc variables

//*****************************************************************************

// System variables {Name};{Value}

SYSTEMID;model //Name of the system (display in the Script Client)

11.4. sysvars.csv 237 nomos Documentation, Release 1.1.73

11.5 timer.csv

File structure of the timer.csv. The predetermined ﬁle name is obligatory. The time program and the Timer can be changed to the running time. Location: ./[Project]/misc/ // Timer: // {Name};{Type};{Value or Date-string};{Action};{Options}

// {Name} Designation of the Timer // {Type} Type of Timer, “INTERVAL”,”ONESHOT”,”CALENDAR” Configuration of the Timer’s value, with “INTERVAL” or // {Value} “ONESHOT”: // Seconds (max. 86400 (= 1 day) possible) // {Date-string} Configuration of the Timer’s value, with “CALENDAR”: // {nothing entered} - fires every day at midnight // 13 - fires every day at 13:00 hours // 13:04 - fires every day at 13:00 hour plus 4 minutes // 13:04:05 - fires every day at 13:00 hours plus 4 minuten and 5 seconds // MON - fires at start of every Monday on the stroke of midnight // WED,13:04 - fires every Wednesday at 13:04 hours // WED,MON,13 - fires every Wednesday and Monday at 13:00 hours // THU,13,29.11. - fires every Thursday at 13:00 hours // since day of week is given (priority) // 13,12. - fires every 12th of the month at 13:00 hours // 24.12.,18 - fires every Christmas Eve at 18:00 hours // 13,25.12. - fires Christmas Day at 13:00 hours // // Syntax variants: {Date-string}~{Varianz} // // ~{Seconds} // ~{Minutes}:{Seconds} // ~{Hours}:{Minutes}:{Seconds} // // {Action} mmh sequence or script name to be carried out // {Options} further options in timer configuration currently possible. // Multiple choices are separated by ”,” : // AUTOSTART - starts the Timer upon system boot up // IMMEDIATE - fires the Timer also upon system’s start // [CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Extended protocol active {“YES”/”NO” - Default}

[TIMERS]; // {Name};{Type};{Value};{Action};{Options}

11.5. timer.csv 238 nomos Documentation, Release 1.1.73

// Examples: // TIME;INTERVAL;60;;AUTOSTART; // permanent Timer that queries the system’s time every 60s // CAL;CALENDAR;21:35;;AUTOSTART; // Fires daily at 21:35 hours // CAL;CALENDAR;22:30~600;;AUTOSTART; // Timer with variance, ﬁres daily between 22:25 and 22:35 hours

11.5. timer.csv 239 nomos Documentation, Release 1.1.73

11.6 baos.csv

File structure of the baos.csv. Fixed ﬁle name is obligatory. Location: ./[Project]/misc/ // Deﬁnitions table for the employment of the Weinzierl BAOS 770 Interface (Object server)

[CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Extended protocol active {“YES”/”NO” - Default} BAOSIP;AUTO // {IP} - IP of the KNXBAOS (ﬁxed) - // {AUTO} - IP of the BAOS is sought out - // {OFF}- BAOS function turned off

[DATAPOINTS]; // Reported datapoints, as conﬁgured in the ETS // {Object number};{Name of datapoint can be chosen at will};{Object Type "DEC","HEX", "ASCII"} [ACTIONS]; // {Object number};{Value};{Action};{Object Type "DEC","HEX", "ASCII"} // When {Object Type} is not set, default = HEX // Examples: // 1;1;;DEC; // Starts a Script // 2;#;;DEC; // Sets system sound volume to the value of 5/2/2

11.6. baos.csv 240 nomos Documentation, Release 1.1.73

11.7 hs.csv

File structure of the hs.csv. The fixed file name has to be kept. Location: ./[Project]/misc/ // Definition table for the employment of the Gira Homesever KO-Gateway’s

[CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Extended protocol active {“YES”/”NO” - Default} HSIP;192.168.50.65; // IP address of GIRA Home Servers HSPORT;7003; // Port of the KO-Gateway’s HSKEY; // Key, if assigned ADDRTYPE;3STEP //{2STEP} 2-step, {3STEP} 3-step, {empty} decimal/raw

[DATAPOINTS]; // {Internal or external object};{DP name can be chosen freely};{Condition};{Action} //Examples // 5/2/1;iTunes Start;1.0;; // Starts a script, if 5/2/1 = "1" // 5/2/2;Set Volume;;#;; //sets the system sound volume to the value of 5/2/2 // 5/2/8;Volume down;DOWN,100;; // changes the system sound volume, as with a Dim - Command // 5/2/8;Volume up;UP,100;; // changes the system volume like a Dim+ Command

11.7. hs.csv 241 nomos Documentation, Release 1.1.73

11.8 knx.csv

File structure of knx.csv. File’s predetermined name is obligatory. Additionally needed is the .esf file, which can be generated from the ETS. The .esf file must be present in the same index as the knx.csv. Location: ./[Project]/misc/ // Definitions table for the employment of the KNXnet/IP protocol // Supported EIS typea in the esf file: // // EIS 1 ’Switching’ (1 Bit) // EIS 2 ’Dimming - position’ (1 Bit) // EIS 2 ’Dimming - control’ (4 Bit) // EIS 2 ’Dimming - value’ (8 Bit) // EIS 3 ’Time’ (3 Byte) // EIS 4 ’Date’ (3 Byte) // EIS 5 ’Value’ (2 Byte) // EIS 6 ’Scaling - percent’ (8 Bit) // EIS 6 ’Scaling - degree’ (8 Bit) // EIS 7 ’Drive control’ (1 Bit) // EIS 8 ’Priority - position’ (1 Bit) // EIS 8 ’Priority - control’ (2 Bit) // EIS 9 ’Float value’ (4 Byte) // EIS 10 ’16Bit Counter’ (2 Byte) // EIS 11 ’32Bit Counter’ (4 Byte) // EIS 12 ’Access’ (4 Byte) // EIS 13 ’EIB-ASCII-Char’ (8 Bit) // EIS 14 ’8Bit Counter’ (8 Bit) // EIS 15 ’Character String’ (14 Byte)

[CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Extended protocol active {“YES”/”NO” - Default} ESF;knx.esf; // Name of the esf ﬁle PHYSADDR;0.0.254; // Physical address of the Daemon ADDRTYPE;3STEP; / {3STEP} o. {2STEP} Presentation of group addresses MATCHLOCAL;NO; // Match also for data sent by Daemon DPTNAMES;NO // Output with descriptive text SENDRATE;10 // {30} = Default, (telegram/s) // scans the deﬁned tables upon starting the engine // „YES/ALL“ = on, INITSCAN;YES; „NO“ = off (Default)

// ****Installation for ROUTING ****

11.8. knx.csv 242 nomos Documentation, Release 1.1.73

// {„TUNNELING“/„ROUTING“-Default} or „TUNNEL- CONNECTIONTYPE;ROUTING ING_BRIDGE“ MULTICAST_IP;224.0.23.12 // {Multicast Address} or {„AUTO“– default}

// **** Installation for TUNNELING **** //CONNECTIONTYPE;TUNNELING //DEVICE_IP;AUTO // **** Installation for TUNNELING_BRIDGE **** //CONNECTIONTYPE;TUNNELING_BRIDGE; //DEVICE_IP;AUTO; //MULTICAST_IP;AUTO; [DATAPOINTS]; // {KNX/EIB group addresses};{Condition};{mmh-Sequence or Scriptname}; // Examples: // 5/2/1;1;; // Starts a script, when 5/2/1 = "1" // 5/2/1;0; ; // Starts a script, when 5/2/1 = "0" // 5/2/2;#;; // Sets VOLSET to the value of 5/2/2 // 5/2/8;DOWN,100; // VOLDN with rel. DIM command // 5/2/8;UP,100;; // VOLUP with rel. DIM command // [TABLE=Wohnzimmer]; // 1/8/4 // Data Scan Address Table

11.8. knx.csv 243 nomos Documentation, Release 1.1.73

11.9 remote.csv

File structure of the remote.csv. The predetermined ﬁle name is obligatory. Location: ./[Project]/misc/ // Deﬁnitions table for the employment of the remote classes.

[CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Extended protocol active {“YES”/”NO” - Default}

[DEVICES]; // {Class name};{IP address AppleTV or remote iTunes}; // // ATV_FIT;192.168.1.40;

11.9. remote.csv 244 nomos Documentation, Release 1.1.73

11.10 xbmc.csv

File structure of the xbmc.csv. The fixed name of the file is mandatory. Location: ./[Project]/misc/ // Definitions table for the use of the xbmc classes.

[CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Extended protocol active {“YES”/”NO” - Default}

[DEVICES]; // {Classname};{IP};{ControlPort};{WebserverPort};{Username};{Password};

// {IP} IP of the XBMC // {ControlPort} Steering Port for the XBMC (optional, default: 9090) // {WebserverPort} Port of the Web server (optional, default: 8080), type info // {Username} User name for the Web server (optional, default “xbmc”) // {Password} Password for the Web server (optional, default “xbmc”) // // XBMC_FIT;192.168.1.40;

11.10. xbmc.csv 245 nomos Documentation, Release 1.1.73

11.11 sonos.csv

File structure of the sonos.csv. Name of the file is fixed and mandatory. Location: ./[Project]/misc/ // Definitions table for using the remote classes.

[CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Extended protocol active {“YES”/”NO” - Default}

[DEVICES]; // {Classname};{IP address or name/designation of the SONOS player}; // // SON_FIT;Fitness;

11.11. sonos.csv 246 nomos Documentation, Release 1.1.73

11.12 mremote.csv

File structure of the mremote.csv. The fixed file name must be preserved. Location: ./[Project]/misc/ // Definitions table for using the mremote modules.

[CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Expanded protocol active {“YES”/”NO” - Default} PORT;5500; // Protocol Port //PORTRAIT;; // {Local action with iPxx upended orientation //LANDSCAPE;; // {Local action with iPxx oriented crosswise //CONNECT;; // {Local action with iPxx interfacing //SPEECHLANGUAGE; {Lang- // chooses language for the speech output (default: en_US) Setting} //SPEECHVOICE;{Voice} // chooses the voice for the speech output (default: (null))

// There is a list of the possible languages and voices here

// IP address of the mRemote Server, or AUTO (AUTO=local IP ad- GUI_IP;AUTO; dress) // Port address of the mRemote Servers or AUTO (AUTO=Port of the GUI_PORT;AUTO; local mRemote Servers)

[DIGITAL];; // {JoinNr};{Type};{Push-Action};{Release-Action};{Push-Event};{Release Event};NOCACHE;{Local- Action};{Parameter}; [ANALOG];;; // {JoinNr};{Value};{Scale};{Action};{Event};NOCACHE;{Local-Action};{Parameter}; [SERIAL];;; // {JoinNr};{Value};{Action};{Event};NOCACHE;{Local-Action};{Parameter}; [LIST];;; // {JoinNr}};{Value};{Action};{Event};NOCACHE;{Local-Action};{Parameter} [PAGE];;; // {Page Match};{Action};

11.12. mremote.csv 247 nomos Documentation, Release 1.1.73

11.13 logic.csv

File structure of the logic.csv. File name is ﬁxed and obligatory. Location: ./[Project]/misc/ // Deﬁnitions table for using the Logik Module.

[CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Expanded protocol active {“YES”/”NO” - Default}

[OBJECTS]; // {Object name};{Match};{Initial value};{Channel};ONCHANGE;

// {Object name} - - Name of the object // {Match} - Match string for the value of the object // {Initial value} - Value initially assigned to the object (optional, default: 0) - Analyzer channels (IN/OUT/BC), on which matching is to be done // {Channel} (optional, default: IN,OUT,BC) // ONCHANGE - triggers logic (see below) only with value changes

// Example: //MYVOL;\%|VOL=\*|;;BC,OUT;ONCHANGE; // matches to the system volume in the OUT- and BC-channel and Text entered here describes object MYVOL [LOGIC]; // {expression in logic};{positive action};{negative action};{Triggerlist};ONCHANGE

// {logic expression} - conjunctions of objects, sysvars and constants - action that is to be carried out upon a logical “true” of the {logic // {positive action} expression}, objects can be inserted with [[ ]] . - action to be carried out when there is a logical “false” of the {logic // {negative action} expression}, objects can be inserted with [[ ]] - list of all objects and sysvars, which collide in the analysis of the // {Trigger list} {logic expression} (optional, default: all Objects and Sysvars out {logic expression}) - triggers the positive or negative action only when the value of the logic // ONCHANGE expression has changed (true -> false or false -> true) (optional)

// Operands from {logic expression}:

// {Object name} - content of the object {Object name} or JoinNr {dxxx, axxx, sxxx} // [{Sysvarname}] - Content of the Sysvar {Sysvarname} // “{Constant}” - constant value // // logic links

11.13. logic.csv 248 nomos Documentation, Release 1.1.73

// ! - “NOT” - logical NOT, can come before operands and brackets // | or || - “OR”, Operand a or Operand b is true // & or && - “AND”, Operand a and Operand b are true // // Comparator: // = or == - “EQUAL” - Operand a is equal to Operand b // != or <> - “UNEQUAL” - Operand a is not equal to Operand b // > or >> - “GREATER” - Operand a is greater than Operand b (numerically only) // < or << - “SMALLER”, - Operand a is smaller than Operand b (numerically only) // >= or => - “GREATER-EQUAL” - Operand a is greater than or equal to Operand b (numerically only) // <= or =< - “SAMLLER-EQUAL” - Operand a is smaller than or equal to Operand b (numerically only) // Calculation rule: // () - evaluation of terms inside parentheses has priority

11.13. logic.csv 249 nomos Documentation, Release 1.1.73

11.14 zwave.csv

File structure of zwave.csv. The predetermined file name is obligatory. No csv is required in the configuration mode. This file is automatically docked in the configuration mode. Location: ./[Project]/misc/ // Definitions table for the employment of the Z-Wave classes.

[CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; / Expanded protocol active {“YES”/”NO” - Default} // “AUTO” or serial port to which the zwave controller is connected PORT;AUTO (/dev/ttyS1, /dev/ttyUSB0 etc... ), optional, default: AUTO

[NODES]; // {NodeIndex};{Desired name of node} // 5;DIMMER; // 6;SWITCH;

11.14. zwave.csv 250 nomos Documentation, Release 1.1.73

11.15 xpl.csv

File structure, possible parameters and command set of the xpl definitions. The name of the file defines the class names. Following example is for the Squeezbox of Logitech Location: ./[Project]/xpl/ // Definitions table for the use of the Z-Wave classes.

[CONFIG]; ACTIVE;YES; // activate module {“YES” - Default/”NO”} DEBUG;NO; // Extended protocol active {“YES”/”NO” - Default} TARGET;slimdev-slimserv.SB1 // Name of the Squeezbox

[SCHEMA=audio.slimserv]; PLAY;COMMAND=PLAY; STOP;COMMAND=STOP; VOLUME;COMMAND=VOLUME \#; NEXT;COMMAND=SKIP; PREV;COMMAND=BACK; RANDOM;COMMAND=RANDOM; CLEAR;COMMAND=CLEAR; PAUSETOGGLE;EXTENDED=pause; PAUSEON;EXTENDED=pause 1; PAUSEOFF;EXTENDED=pause 0; PLAYFILE;EXTENDED=playfile \#; SETPTIME;EXTENDED=time \#; SLEEP;EXTENDED=sleep \#; POWERON;EXTENDED=power 1; POWEROFF;EXTENDED=power 0; ADDANDPLAY;EXTENDED=playlist play \#; ADD;EXTENDED=playlist add \#; INSERT;EXTENDED=playlist insert \#; MOVE;EXTENDED=playlist move \# \#; DELETE;EXTENDED=playlist delete \#; RESUME;EXTENDED=playlist resume \#; SAVE;EXTENDED=playlist save \#; LOADALBUM;EXTENDED=playlist loadalbum \# \# \#; ADDALBUM;EXTENDED=playlist addalbum \# \# \#; JUMP;EXTENDED=playlist index \#; SHUFFLEON;EXTENDED=playlist shuffle 1; SHUFFLEOFF;EXTENDED=playlist shuffle 0; NOREPEAT;EXTENDED=playlist repeat 0; REPEATSONG;EXTENDED=playlist repeat 1; REPEATPLAYLIST;EXTENDED=playlist repeat 1; RESCAN;EXTENDED=rescan;

11.15. xpl.csv 251 nomos Documentation, Release 1.1.73

[SCHEMA=audio.request]; STATUS;COMMAND=STATUS;

[WATCH=audio.basic]; // processing of responses status;STATE; ARTIST;ARTIST; ALBUM;ALBUM; TRACK;TITLE; POWER;POWER;

11.15. xpl.csv 252