Skip to content

Observables are data that is constantly monitored. When the data matches a criteria, a set of actions is executed.

For people familiar with the concept, it can be considered a if-this-then-that instruction. For example: If the weather data from the simulator indicates rain is falling on the aircraft, we can set the windshield wipers automatically.

There are two types of observables.

Permanent Observables are coded observable serving a very specific purpose. The purpose often includes complex data transformation before it can be used by Cockpitdecks. Permanent Observables are derived from the Observable class. When identified, they all are instantiated and started. Permanent observables are part of extensions.

Example of a Permanent Observable convert (latitude, longitude) into the closest weather station ICAO code. This cannot be done by simple calculations in a Formula.

Configured Observables, or simply Observables, are entities that monitor one or more variables and perform instructions when observable conditions are met. Configured Observables are defined at three levels:

  1. the cockpit level, available for the entire application, mostly all the time,
  2. the simulator level, available to monitor simulator-specific variables,
  3. the aircraft level, available to monitor aircraft-specific variables.

Configured Observables are defined in resources folder of the entity in a observables.yaml file. All observables are loaded at once in an Observables entity which contains them all and report their use .

Definition of Observables

The file observables.yaml is located in the deckconfig/resources folder of an aircraft. It is loaded on startup.

observables:
  - name: example
    trigger: onchange
    dataref: some/dataref/to/check
    actions:
      - command: do/some/action
        delay: 5

Attribute

Observables

The observables attribute is a list of individual observables.

Observable

Attributes

Type

What triggers the observable.

Trigger

type: trigger

The list of action is carried over when the value of the observable is True (or non zero).

Value Changed

type: onchange

Another method to trigger the flow of action(s) is to select the value changed mode. Actions get executed as the value of the dataref or of the computation has changed.

Activity

type: activity

The observable will look for the event or events attributes and register interest in the events listed under these attributes.

Each time the simulator software will report those events, the actions will be carried over.

Repeat

type: repeat

The observable will automatically be triggered every replay seconds after a delay seconds at the start

Actions

The actions attribute is a list of individual actions that gets carried out in sequence if the trigger attribute is True.

Action

Attributes

An action as the same attribute as a command carried out by a button:

  • instruction
  • delay
  • condition

Examples

Here are a few examples of Observables, set from experience.

Simulation Event

Internal Changes

When a new aircraft is loaded, or when an aircraft livery is changed, "internal" events are generated by the simulator software so that external entities like Cockpitdecks can be notified.

This is how Cockpitdecks detects aircraft or livery changes. Action triggered are very specific (to change the aircraft).

So, internally, Cockpitdecks uses an Observable that monitors a simulator variable that changes when a new aircraft or mivery is loaded. This depends on the

Aircraft Events

Auto Save on Event

Most simulators or aircrafts provide a command to save the situation and restore it later.

ToLiss aircrafts simulate Airbus which have the concept of flight phase.

We devised an Observable to trigger a situation save on flight phase change. This allows to restart a flight right at the flight phase change.

Complex Observables

A few packages come with special, coded Observables to serve very particular purpose. In most case, triggers or value changes are impossible to map with simple formula operation and require further coding.

Complex Obervables are automatically loaded on startup and are accessible through the rendez-vous internal variable.

Weather Station

The Weather Station observable determine the ICAO code of the weather station that is the closest to the aircraft.

The Observable receives the aircrat latitude and longitude and determine the closest weather station. The ICAO code is written in an internal variable weather-station.

The Observable is available in the X-Plane package as it requires the aircraft location.

Daytime

The Daytime obsrvable receives the simulated date, time, and position of the aircraft and determine whether it is day or night time. Day is assumed between sunrise and sunset as computed for the location and time of year. Daytime or nighttime keyword is written in an internal variable daytime.

The internal variable can be used to declare another Observable that, for instance, changes the theme of the deck interfaces from light to day or vice-versa.

The Observable is available in the X-Plane package as it requires the aircraft location and the currently simulated date and time.

Command Activation

The newer X-Plane Web API allows for reporting when a command is activated. It is possible to capture when some action was executed by the user and, through observable, start another set of commands.

For exemple, when a warning alarm is triggered (an event that can be captured through dataref value change), when the pilot or co-pilot presses the warning button to acknowledge it, we can capture the press of the button and start new action like performing a situation save.