Skip to end of metadata
Go to start of metadata


The Miniserver doesn’t have a simple function to ingest Text strings. A Virtual Input can, however, ingest a single character. Further, we can build a string of characters using Status Blocks. The method is somewhat tedious to set up, however it does have the benefit of being contained entirely within the Miniserver. ie. a separate server is not required.

The primary motivation for this function is to send a variable text string to a Text-to-Speech output. The secondary motivation is to provide a text field in the Loxone App.

The attached Loxone Config file contains the populated Status Blocks (note - the file does not include Virtual Inputs due to a bug when copying VI's in Loxone Config version This framework can be adapted to any text field including web-pages, calendars, RSS feeds etc. The following is an example from an RSS feed –

Text Input to Miniserver.Loxone

There are 53 Status Blocks connected in this file (which creates a 53 character text string). This number simply represents a comfortable amount of Status Blocks that can fit on one Config tab. More characters can be added using additional Status Blocks if required.

If less characters are required, delete Status blocks from the end of the chain, working back towards the beginning.

Adjusting Command Recognition

The Virtual Inputs need to be created and adjusted to the desired application. Command Recognition in the Virtual Input has a facility to ingest single bytes. This is done with the following example from a CalDAV-4-Lox calendar event –

"Summary": "\s0\1

This will ingest the first byte from the summary field of a calendar title (ie. a single text character after ").

"Summary": "\s1\1

"Summary": "\s2\1

The next two VI’s above will ingest the second and third bytes (text characters) in the summary field of a calendar title.

You will need to create as many Virtual Inputs as dictated by the largest expected text length.

Important - The Miniserver processes the Virtual Inputs in the order they were created. The processing order is essential for the correct functioning of the text recognition. For this reason, create the Virtual Input called 'Byte 1', then create 'Byte 2', then create 'Byte 3' etc.

Failure to observe this will cause errors in the text recognition.

The values returned to the Miniserver will be the ASCII decimal value (Dec) for the particular character (Chr). For standard characters, those values are as follows -

Standard ASCII Table

The word ‘The’ will be interpreted as 84 (T), 104 (h), and 101 (e)

The string of Status Blocks acts as a simple ASCII to text converter. Each Status Block derives one character, then appends it to the previous block’s text string. The sequence cascades until a delimiter is encountered.

Hover the cursor over the TQ field with Liveview active to see the current text string.

The Delimiter

In the case of CalDAV-4-Lox, the delimiter is the next instance of " (quotation mark). We need to create sufficient Virtual Inputs to cover the largest expected text length for what might be a variable length text string. For shorter length text strings, we then need to identify where the text stops by recognising the delimiter.

The Status Blocks continue to cascade the text sequence but do not add any characters from the " symbol onwards. The ASCII decimal value for " is 34.

The ‘Unique 1st Block’ has an empty Status-text value against Value 34. This means that no character will print for value 34.

The ‘Repeating block’ has the Status-text as <v1>, but doesn’t add any more characters because the previous block was a delimiter ". The ‘State value’ 34 is output to subsequent blocks. This means they also won’t add characters.

Different delimiters might be used for different applications. If this is the case, modification of the Status Block is required.

Delimiter for RSS Feed

An example RSS feed is given below. In this case the delimiter is the < (less than symbol).

To alter the example file to suit this RSS feed, it is preferable to delete all Status blocks except for the ‘Unique 1st Block’ and the first ‘Repeating block’. After modifying the ‘Repeating block’, it will need to be copied multiple times and connected as originally done (a simple but tedious process…)

The ‘Unique 1st Block’ will need the following modifications.

  1. Add in the " (quote) symbol in-line with Value 34. We want this symbol to be printable again.
  2. Delete the Status-text in-line with Value 60. The ASCII decimal value for the < symbol is 60 and we don’t want it to print.

The ‘Repeating block’ will need to be modified at four places –

  1. AI2 = 60. This is because 60 is the ASCII decimal value for the < symbol,
  2. Status-text = <v1> and State value = 60,
  3. The value for 34 can be returned to a printable character by placing " (quote) after the <v1>,
  4. Change AI3 = 60 to a non-printable character by deleting the symbol < after <v1>.

Now copy and paste the ‘Repeating block’ multiple times and join up….!

If you wish to check progress at any stage, create a link from the TQ output of the last 'Repeating block' and join to the input of the 'Virtual Status' block.

Extended ASCII Characters

Some provision has been made for Extended ASCII characters in the text recognition. Those characters are -

ä   Ä   ö   Ö   ü   Ü   ß   €   £

These characters require more than one byte for recognition. In the case of the euro , the symbol requires 3 bytes. The values presented by the symbol are 226, 130, and 172.

The ‘Unique 1st Block’ has an empty Status-text against value 226. The ‘Repeating block’ has the logic nested within a single block, but the process identifies the character over three blocks.

Using this method, additional Extended ASCII Characters can be added as desired.

Where a character is not defined in the Status Block, the Status Block will print a blank space.

Eg. Test this symÃbol.

Related Articles