Loxone UDP/HTTP Command Parser Syntax

Loxone can parse incoming data e.g. via UDP/HTTP to detect variables. I found their documentation not really good. It feels like it is almost an art to setup these parse strings, while it is actually quite simple.

The string is searched in the incoming data stream. If the full string is detected, it succeeds and returns the value (0.0 being the default). If it didn’t match the whole pattern within the stream, it resets and continues again to parse the data. Only if the whole string was parsed fully, will the matching stop.

Possible characters in the parse string

Matching individual characters

  • 7-bit ASCII characters: they are taken as-is and need to match
  • \\ matches a single \ (0x5C)
  • \n matches a LF (0x0A)
  • \r matches a CR (0x0D)
  • \t matches a TAB (0x09)
  • \xAB match a hex byte AB. This allows matching non-ASCII characters. \xAB would match 0xAB.
  • \a match a letter (A-Z, a-z)
  • \b match a TAB or space (0x09, 0x20)
  • \m match a letter or digit (A-Z, a-z, 0-9)
  • \d match a digit (0-9)
  • \. matches any byte (= skips/ignores one byte)

Matching multiple characters

  • \# match any number digits and . , or -. This should match a regular floating point number and continue after the number.
  • \w match any number of letters and digits (A-Z, a-z, 0-9). This should match a word and continue after that word.
  • \s123 skips/ignores 123 bytes in the incoming data stream. All digits following \s are using to build a number, the value can be really large – more than is ever needed.

Searching

  • \iXXX\i searches the string XXX and continues after that string with matching. The string can have standard UNIX control characters (\a, \b, \f, \n, \r, \t, \v plus the hex extension: \xAB).

Storing a value

The returned value is always a 64-bit floating point number, which can result in rounding issues for certain integer values.

  • \1…\8 stores the following byte as part of a 64-bit binary integer result. \1 is the LSB, \8 is the MSB. Sign-extension can be applied.
  • \h (hex value) stores the following ASCII-hex data (0-9, a-f, A-F) as a 32-bit MSB integer result. First invalid character ends the value. The value is returned as-is, no sign extension is applied.
  • \v (value) stores a value created from ASCII characters. Any number of spaces before the values are ignored. Then the optional sign (+ or -) can follow, plus more spaces. A &nbps; is ignored after the sign as well. The number is any number of digits (0-9) followed by (, or .) plus more digits. Then an exponent (E or e) can follow plus more digits. The first character not matching the described number will end the value. The resulting number is obviously a floating point value.
  • If \f (factor?) is part of the search term, the value will always be 0.0. This feels like a bug in the code and \f was probably thought to be a multiplication factor for the incoming value.

It is possible to have several \h and \v in the search pattern. Only the last one will be used. Same with \1, etc. If more than one \1 occurs, the first one will be ignored as well.