Think of the Action Steps as connectable parts that have an input and an output pipe. Each Step waits for incoming objects (in cv.Payload) it can then process and pass on through the output pipe to the next Step. Before processing the Step, you can Pre-Map and after processing the Step you can Post-Map the cv.Payload variable.

To inspect the action variables coming through, you can enable debugging (see below) and inspect the Actmgr logfile. In the example here, you can see the tv. variables outputted by a temperature sensor:

You can therefore access the values of these variables using tv.AreaId, tv.AreaName, tv.Data, tv.KindId etc. read from down to up chronologically.

There are 6 broad categories of Variables in Gravio:

Action Property

Referred to by adding a prefix of ap.
Action Properties can be defined as a property passed from the outside the Action when the Action is executed.

Action Variable

Referred to by prefixing av.
Action Variables are variables that can be referenced within an action. This could be for example Sensor Data.

Component Property

Referred to by prefixing cp.
A Component Property is a value that determines the behaviour of a component. They differ vastly between different types of components.
For example, the POST component might have an URL as property, whereas the Gravio Light component has some color and illumination settings of the Gravio Light.

Component Variable

Referred to by prefixing cv.
Some variables are implicitly declared in the component.
For example, the cv.StatusCode contains the HTTP status code and response headers of the HTTPRequest Component.

To find out what the respective Component’s cv. values are, please refer to the documentation of the respective Component.

Trigger Property

Trigger properties set by event triggers and timer triggers can be referenced in actions.
Referenced by prefixing it with tp.
For example tp.KeyAreaName

Trigger Variable

Referenced by adding a prefix of tv.
The data sent by the sensor can be referenced in the Action program with the following trigger variables

Trigger Variable Description
tv.AreaId Area ID
tv.LayerId Layer ID
tv.KindId Data Kind ID
tv.PhysicalDeviceId Device ID of the sensor
tv.Timestamp The time when the data was output from the sensor. The format is RFC3339Nano.
tv.DataId This sensor data unique ID
tv.Data The value of the sensor data. tv.Data will be the same as the first component’s cv.Payload

Value (type)

Variable Type Description
Int Integer
Float floating point number
String String , Strings can be concatenated with +, for example "The value from the sensor is " + tv.Data
Bool true/false
DateTime Date Time
Byte sequence Byte sequence
Array Array
Object Object
Type Example
literal [1, 2, 3]
Array ["abc", "def", "hij"] ["abc", 123, cv.variable]
Object {"key1":123, "key2":"abc", "key3":cv.variable, "key4":[1, 2, 3], "key5":{"subkey1":"def"}}

Type Conversion

It is possible to convert from each type to each type.

Type Example
  • The numeric system is false when it is 0 and true otherwise.
  • If the date and time is 0 in Unix time, it is false, otherwise it is true.
  • True if the string is “true”/“1”, false otherwise.
  • Byte strings follow string rules after being converted to strings
  • false for any other type.
  • Boolean is 1 when it is true, 0 otherwise.
  • Floating decimals are a Go language casting rule
  • At the time of the date and time, the Unix time is a number.
  • For strings, follow the rules of strconv.ParseInt
  • Byte strings follow the string rules after being converted to strings. The other types are 0
  • Boolean is 1.0 if it’s true, 0.0 otherwise
  • Integer is a Go language casting rule
  • At the time of the date and time, the Unix time is a number.
  • In the case of a string, the rules of strconv.ParseFloat are followed
  • Byte strings follow string rules after being converted to strings
  • 0.0 for all other types.
  • Boolean is “true” if it is true, otherwise it is “false”.
  • Convert integers to strings using strconv.FormatInt and floats to strings using strconv.FormatFloat
  • If it is a date and time, fix it as a string in time.RFC3339Nano format.
  • Byte sequence is regarded as a string of utf-8 bytes. If there is an error, an empty string
  • Array and Object are made into a string by multiplying by json.Marshall
  • Numeric systems and Boolean are converted to integers by a rule that converts them to integers, and then converted to date and time by a rule that converts them to Unix time
  • For the string, if the following formats are tried in order, they are considered to be date and time, otherwise they are 0 (0 for date and time is 1 January 1, 00:00:00). time.RFC3339Nano, “2006-01-02T15:04:05.999 MST”, “2006-01-02T15:04:05.999”, “20060102T150405.999 MST”, “20060102T150405.999”,
  • The same rules as for strings
  • Otherwise, zero.
byte sequence
  • Boolean, numeric system and date/time are changed to strings and made into a utf-8 byte string
  • The string should be a utf-8 byte string
  • Array, Object can write json.Marshal and make the string a byte string
  • Array, Object numeric system and the date and time should be an array containing one of its values
  • Unmarshal the string as JSON string. In case of an error, an array of size 0
  • Byte strings are rewritten as strings, same rules as strings The array and objects are still in the
  • Any other type is an array of size 0


You can easily dump the value of all variables by activating the “debug” button on the top left corner of the step. If you enable it, Gravio will dump all variables to the console at the bottom:

The variable values are also dumped in the actmgr logfile, which you can inspect in the logfile area of Gravio.

The variable handling in Gravio follows the schema according to

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.