Difference between revisions of "Virtual Outputs"

From OpenMotics
Jump to navigation Jump to search
Line 37: Line 37:
 
  error list                            ;Error list will indicate all modules created in the system
 
  error list                            ;Error list will indicate all modules created in the system
  
A virtual output module can also be created by API instruction "AV", see [[API Reference Guide]] for more details. When creating a virtual module through the API, after creation, the instruction "MI" will be sent from the Master to the BB.
+
A virtual output module can also be created by API instruction "AV", see [[API Reference Guide]] for more details. When creating a virtual module through the API, the instruction "MI" will be sent from the Master to the BB.
  
 
When a Virtual Output state changes, the same API instruction ("RO" and/or "OL") will be sent to the BB as with a Normal Output that changes state.
 
When a Virtual Output state changes, the same API instruction ("RO" and/or "OL") will be sent to the BB as with a Normal Output that changes state.

Revision as of 20:08, 23 March 2016

Introduction

The Openmotics system supports following virtual devices:

  • Virtual Inputs: For example a doorbell that sends a push notification is translated in an action that switches on a light in the house
  • Virtual Outputs: For example a Philips Hue light that acts as a virtual output can be switched on by a normal switch on the Openmotics system (or a virtual switch)
  • Virtual Sensors: Any non-openmotics sensors like Z-wave wireless temperature, NEST thermostat temperature and humidity, third party light sensors etc can be used when the right plug-in is written


How does all the Virtual stuff works?

The master firmware (as of F3.142.1) allows you to create virtual output modules. Once a virtual output (or dimmer) module is created, you have 8 virtual outputs. Those virtual outputs can be changed state by using all regular Basic Action and can be programmed like any normal output and can be linked to any input, can be used in any group action or other action. When a virtual output changes state, instruction "RO" and/or "OL" will sent depending how your Master is configured.

See Virtual Plug-in Examples for more information how to use this in combination with the plug-in system.

Virtual Outputs (Available in firmware version 3.142.1 and higher)

As of Firmware Version F3.142.1 and higher, the master allows virtual outputs. The number of virtual output modules that can be created is only limited by the system limits (maximum 240 outputs or 30 output modules). These are the type of non-virtual modules which exist as Virtual and Normal (Non-Virtual):

  • "I" -> Normal Input module
  • "i" -> Virtual Input module
  • "T" -> Normal Sensor module
  • "R" -> Normal Roller/Shutter module
  • "O" -> Normal Output Module
  • "o" -> Virtual Output Module
  • "D" -> Normal Dimmer Module
  • "d" -> Virtual Dimmer Module

As you can see, there is no virtual alternative for the Sensor module since no Virtual Sensor module exists. The Master has 32 sensors and for each sensor, you can choose whether that sensor is Virtual or Not. For more information, see Virtual Sensors

Configure Virtual inputs

A virtual output module can be created by using following CLI instruction:

add virtual module o                   ;Create a Virtual output module

or

add virtual module d                   ;Create a Virtual dimmer module

The created modules can be easily checked with following instruction:

error list                             ;Error list will indicate all modules created in the system

A virtual output module can also be created by API instruction "AV", see API Reference Guide for more details. When creating a virtual module through the API, the instruction "MI" will be sent from the Master to the BB.

When a Virtual Output state changes, the same API instruction ("RO" and/or "OL") will be sent to the BB as with a Normal Output that changes state.