Difference between revisions of "Introduction to I/O Servers"

From HSYCO
Jump to navigation Jump to search
Line 5: Line 5:
 
The first step when integrating a new system is to configure the corresponding I/O Server. This is accomplished using the [[Settings#I/O_Servers|I/O Servers section]] of the [[Settings]] application accessible through the [[Manager]].
 
The first step when integrating a new system is to configure the corresponding I/O Server. This is accomplished using the [[Settings#I/O_Servers|I/O Servers section]] of the [[Settings]] application accessible through the [[Manager]].
  
From here you can specify the communication parameters and its options. Details of this settings are provided in the [[I/O Servers|I/O Servers application notes]] for each integrated system.
+
From here you can define a new I/O Server, set its ID and specify the communication parameters and its options. Details of this settings are provided in the [[I/O Servers|I/O Servers application notes]] for each integrated system.
 +
 
 +
The ID of the I/O Server is used to reference it in the HSYCO environment.
  
 
== Using Datapoints ==
 
== Using Datapoints ==
 +
A datapoint is univocally identified by the combination of the I/O Server ID and the name of the datapoint using the format <io_server_id>.<datapoint_name>.
 +
 
All the available datapoints for an I/O Server are detailed in its application note. A datapoint can be ''readable'' (R) and/or ''writable'' (W).
 
All the available datapoints for an I/O Server are detailed in its application note. A datapoint can be ''readable'' (R) and/or ''writable'' (W).
  
Line 58: Line 62:
 
This table specifies that this I/O Server has 2 datapoints: "foo" and "bar". If we read the "foo" datapoint, we can see 2 possible values: "1" or "2", further we can write only the value "reset" to it.
 
This table specifies that this I/O Server has 2 datapoints: "foo" and "bar". If we read the "foo" datapoint, we can see 2 possible values: "1" or "2", further we can write only the value "reset" to it.
 
On the other hand the "bar" datapoint can be read in three different states ("a", "b" or "unknown") and we can set it to the values "a" and "b".
 
On the other hand the "bar" datapoint can be read in three different states ("a", "b" or "unknown") and we can set it to the values "a" and "b".
 +
 +
Assuming we assigned the ID "ios" to this I/O Server, we will reference these datapoints as <code>ios.foo</code> and <code>ios.bar</code>.
  
 
{{note|If a datapoint is both readable and writable, writing a value to it doesn't mean that a subsequent reading will yield the same value, it simply means that we are issuing a command to the I/O Server. For instance, after setting a datapoint representing a light to "on", we will continue reading its value as "off" until the field system notifies HSYCO that the light is actually on}}
 
{{note|If a datapoint is both readable and writable, writing a value to it doesn't mean that a subsequent reading will yield the same value, it simply means that we are issuing a command to the I/O Server. For instance, after setting a datapoint representing a light to "on", we will continue reading its value as "off" until the field system notifies HSYCO that the light is actually on}}
Line 65: Line 71:
  
 
Events example:
 
Events example:
  IO
+
  IO ios.foo = 1 : ...
 +
 
 +
JavaScript example:
 +
<syntaxhighlight lang="javascript">
 +
function IOEvent(name, value) : {
 +
if (name == 'ios.foo' && value == '1') {
 +
...
 +
}
 +
}
 +
</syntaxhighlight>
 +
 
 +
Java example:
 +
<syntaxhighlight lang="javascript">
 +
static void IOEvent(String name, String value) {
 +
if (name.equals("ios.foo") && value.equals("1")) {
 +
...
 +
}
 +
}
 +
</syntaxhighlight>
 +
 
 +
Events are generally triggered whenever the readable datapoint's value changes, but some datapoints may trigger events even if the value is unchanged. This is done to better fit the behavior of some field systems and is specified in the I/O Server application note.

Revision as of 17:08, 28 February 2014

An I/O Server is the logical representation of a field system integrated in HSYCO. A field system can be, for instance, a security system, a BUS network or even something more abstract as weather information gathered from the internet.

All I/O Servers provides for datapoints through which they receive commands and/or trigger events. That is, you can use these datapoints in your programming logic or user interface to send commands to the field system or to act upon its changes.

The first step when integrating a new system is to configure the corresponding I/O Server. This is accomplished using the I/O Servers section of the Settings application accessible through the Manager.

From here you can define a new I/O Server, set its ID and specify the communication parameters and its options. Details of this settings are provided in the I/O Servers application notes for each integrated system.

The ID of the I/O Server is used to reference it in the HSYCO environment.

Using Datapoints

A datapoint is univocally identified by the combination of the I/O Server ID and the name of the datapoint using the format <io_server_id>.<datapoint_name>.

All the available datapoints for an I/O Server are detailed in its application note. A datapoint can be readable (R) and/or writable (W).

Let's introduce these concepts with an example. Assume an I/O Server has the following datapoints table:

ID Value R/W Description
foo 1 R ...
2 R ...
reset W ...
bar a R ...
W ...
b R ...
W ...
unknown R ...

This table specifies that this I/O Server has 2 datapoints: "foo" and "bar". If we read the "foo" datapoint, we can see 2 possible values: "1" or "2", further we can write only the value "reset" to it. On the other hand the "bar" datapoint can be read in three different states ("a", "b" or "unknown") and we can set it to the values "a" and "b".

Assuming we assigned the ID "ios" to this I/O Server, we will reference these datapoints as ios.foo and ios.bar.

If a datapoint is both readable and writable, writing a value to it doesn't mean that a subsequent reading will yield the same value, it simply means that we are issuing a command to the I/O Server. For instance, after setting a datapoint representing a light to "on", we will continue reading its value as "off" until the field system notifies HSYCO that the light is actually on


Readable Datapoints

The main use for readable datapoints is to execute actions when they trigger an event. This can be done in Events Programming using the "IO" event keyword or in JavaScript or Java Programming using the callback method IOEvent.

Events example:

IO ios.foo = 1 : ...

JavaScript example:

function IOEvent(name, value) : {
	if (name == 'ios.foo' && value == '1') {
		...
	}
}

Java example:

static void IOEvent(String name, String value) {
	if (name.equals("ios.foo") && value.equals("1")) {
		...
	}
}

Events are generally triggered whenever the readable datapoint's value changes, but some datapoints may trigger events even if the value is unchanged. This is done to better fit the behavior of some field systems and is specified in the I/O Server application note.