RFXCOM RFXtrx433 Spezifikationen PDF herunterladen (Seite 61)

Chapter 4. Implementation 54

device ID to optimize the seek time. When accessing the database with those keys, the device ID

is ﬁrst fetched from the corresponding ID-conversion list and then the device structure is obtained

with it. Otherwise, every entry of device list would have to be searched, which would be very

slow. Pointers instead of the ID cannot be used in this case, as the QHash container changes

memory addresses with each copy. The transmitter and receiver QHash lists are almost the same,

except that the receiver on/oﬀ-code lists use the class QMultiHash instead of the normal QHash.

QMultiHash is derived from QHash and allows multiple entries with the same key, which is not

possible in the normal QHash class. This is necessary, because transmitters can be connected with

a number of receivers, thus some on/oﬀ-codes have to be saved multiple times with diﬀerent IDs.

As each transmitter has a unique address and therefore a unique protocol, there is consequently

only one on/oﬀ-code for it and the QHash container is suﬃcient.

In order to maintain the memory based database, it is saved in a XML ﬁle for persistent storage,

which makes it easy to manipulate and transport it. As ﬁle accesses are very slow, the XML ﬁle is

only used for loading during start-up and saving when shutting down the node. During run-time

the ﬁle is not touched, as a result, it can be outdated and does not represent the current internal

database. If it is necessary to update the ﬁle, the "save"-service can do this. An example database

is shown in appendix B on page 76.

The device manager class also contains a service for protocol translation, which enables connections

between devices of diﬀerent HA systems. Every time a protocol message is received, the device

manager checks if its protocol type equals that of the connected receivers. If they are the same,

only the states of the receivers are updated. However, if they diﬀer, a code of the suitable

HA system must be sent to actually switch the receiver. This code is taken from the default

transmitter, consequently, it must be of the same HA type as the receiver. As a result, every

valid connection between two diﬀerent HA systems is composed of at least one receiver and

two transmitters. In case of IT, it would be possible to just send the ﬁxed code of a receiver

without needing the right default transmitter. By contrast, HE receivers have no ﬁxed address.

Instead, they ﬁrst have to learn the address of a transmitter, therefore the connection of the right

default transmitter is stringently required. This drawback, however, is avoidable. By creating a

new transmitter entry in the database with unused on/oﬀ-pairs, the real default transmitter can

be replaced by a virtual, non-existent transmitter. This virtual transmitter can control receivers

without unintentionally changing other receivers that may be connected to the real transmitter.

Three exemplary networks are shown in ﬁgure 4.16 on the following page. Network 1 is invalid

as the default transmitter is not a HE device. When receiving a message from “IT 1”, the device

manager sends the message of the default transmitter, which is in this case “IT 1”. Consequently

the message would be repeated, the receiver “HE 1” would be updated and the physical receiver

would stay unchanged. This causes the database to be inconsistent. Network 2 shows the minimal

conﬁguration with one receiver and two transmitters. Network 3 is a bigger network, which shows

1 2 ... 56 57 58 59 60 61 62 63 64 65 66 ... 94 95

Keine Kommentare

RFXCOM RFXtrx433 Spezifikationen Seite 61