system_objs

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
Next revisionBoth sides next revision
system_objs [2020/07/28 19:48] – ingridsystem_objs [2020/08/06 14:09] – ingrid
Line 40: Line 40:
     * [[#load_control| Load Control]]     * [[#load_control| Load Control]]
     * [[#Gateway_modbus| Gateway Modbus]]     * [[#Gateway_modbus| Gateway Modbus]]
 +    * [[#Gateway_modbus_slave| Gateway Modbus Slave]]
     * [[#gateway_duotecno| Gateway Duotecno]]     * [[#gateway_duotecno| Gateway Duotecno]]
     * [[#gateway_myhome| Gateway MyHome]]     * [[#gateway_myhome| Gateway MyHome]]
Line 233: Line 234:
   * **Restartable** If enabled, the selected scene can be restarted if launched when already running; it is useful when the scenes is full of pauses and it is particularly long-lasting; when the scenery is launched from KNX, this property has to be disabled because of telegram repetitions.   * **Restartable** If enabled, the selected scene can be restarted if launched when already running; it is useful when the scenes is full of pauses and it is particularly long-lasting; when the scenery is launched from KNX, this property has to be disabled because of telegram repetitions.
   * **List of actions** By clicking on the button displayed on the right, the action editor will be displayed; the user can add the desired number of action by clicking on ”Add” button. Each action can be given a name and the related command can be selected by clicking on the button displayed on the right side of the dedicated slot.   * **List of actions** By clicking on the button displayed on the right, the action editor will be displayed; the user can add the desired number of action by clicking on ”Add” button. Each action can be given a name and the related command can be selected by clicking on the button displayed on the right side of the dedicated slot.
 +
 +<WRAP round center 80% tip> Scenes saved by the user from the ThinKnx application are not lost after a project upload to the server. </WRAP>
  
 ==== Object commands ==== ==== Object commands ====
Line 680: Line 683:
 ===== Access Control ===== ===== Access Control =====
 The Thinknx Access Control object permits to enhance the level of automation and security of the home/building where it is applied. It can be adapted to sectors where long term expirations are required such as service and industry sectors, but also applies to the hospitality sector where credentials are usually short term, and remote management is required. The Thinknx Access Control object permits to enhance the level of automation and security of the home/building where it is applied. It can be adapted to sectors where long term expirations are required such as service and industry sectors, but also applies to the hospitality sector where credentials are usually short term, and remote management is required.
- +For more information, check out the Access Control page [[access_control| here]].
-The Access Control object can communicate directly with the KNX system because of the bus connector on the Thinknx server, making the integration very easy and flexible. Any standard KNX keypad can be used as an access keypad, and the buttons as code entries. Once the code is inserted, any lock or switch connected to a KNX actuator can be operated. In addition, communication with Wiegand technology is possible through the Thinknx-Wiegand adapter, making it possible to install a suitable RFID or biometric reader. +
- +
-{{ :access_control_diagram.png?direct&800 |}} +
-<WRAP center 60%> <WRAP centeralign> Access Control Solution </WRAP>  </WRAP> +
- +
-  * **Label** Text to identify the object +
-  * **Code length** Number of digits inside the access codes. All codes should have the same number of digits. If length of codes is 6, a valid code will be 123456. +
-  * **Code numbers** Numbers contained inside the code, starting from 0. This depends on the number of buttons in keypads. If code numbers is 5, codes can contain the numbers 0,1,2,3,4. +
-  * **Confirm time (ms)** Maximum time between two consecutive keypress. Once the confirm time has been exceeded, the start of a new code will considered on keypress. This time is useful to start a new sequence if a mistake has been made when entering the code. +
-  * **Guard wrong codes** if enabled, it is possible to monitor wrong codes attempts, and generate events once a threshold has been reached. +
-    * **Number of attempts** Maximum number of attempts with wrong codes allowed before triggering the event. +
-    * **attempts interval (s)** duration in seconds used to count the number of wrong attempts before triggering the event. If the number of wrong attempts exceeds the number of attempts set previously during the attempt interval, then the event for wrong codes will be fired. +
- +
-==== Keypad prototypes ====  +
-Collection of prototypes used for the installed keypads. To add and configure a prototype, click on the small button to the right to access the prototype creator window. For each added prototype, the following properties are available: +
-  * **Name** label of the prototype used. +
-  * **Technology** technology used for the created protoype. The available options are: +
-    * Doory (Blumotix) +
-    * Generic KNX +
-    * Generic Wiegand //coming soon// +
-    * Wiegand over network //coming soon// +
-If "Generic KNX" was selected as **Technology**, the below parameters are available: +
-  * **KNX Data Type** Data type used on the KNX buttons to send the access code digits. Each button can be configured to send a 1bit object to a different KNX group, or send a certain value on a 1byte object corresponding to the digit on the same KNX group. +
-  * **Delete Key** if enabled, this option will delete the inserted sequence and start a new one before the "confirm time" exipration. +
-  * **Confirm tone** if enabled, the system will generate an event "confirm tone" in case of successful attempt. +
-  * **Keys** //only visible if **KNX Data Type** is DPT 1 (bit).// This parameter holds the keys collection used to enter a code. Clicking on the small right button will open the Keys Manager. From there, it is possible to configure every single key. Each key has a **name**, **key type** and a **group address**. +
-  * **KNX group for keys** //only visible if **KNX Data Type** is DPT 5 (Unsigned byte).// It holds the group address used on the keypad to sen the different code digits. A telegram with value 4 means that button 4 has been pressed on the keypad. +
- +
- +
-==== Keypads ==== +
-This parameter holds the collection of keypads used and installed on the plant. At least one keypad protocol must be created prior adding the keypads. Clicking on the small button to the right will open the Keypads Manager. Each added keypad will have the following parameters: +
-  * **Name** device label +
-  * **Prototype** communication prototype used for this device. A prototype must be created in **Keypads Prototype** in order to view it in the list here. +
-  * **KNX physical address** physical address of the device. +
-  * **KNX group for code enabled** KNX group used by keypad to signal that the code is enabled (1 bit data type). +
-  * **KNX group for storing/deleting codes** KNX group to store and delete codes from the keypad (10 bytes data type). +
-  * **KNX group for erase request** KNX group to erase codes from the keypad (1 bit data type). +
-  * **Command if fail** command to execute in case of failed entry attempt. +
-  * **Command if success** command to execute in case of successful entry. +
-  * **command for tone** command to execute to play tone. +
-==== Areas ==== +
-This parameter holds the collection of all the areas (rooms or part of the building) limited by one or more access control keypads. By clicking on the small button to the right, the Area Manager is accessible. Each added area will have the following parameters: +
-  * **Name** label of the area. +
-  * **Entrance doors** allows you to select the checkers that are used on site to enter this specific area. The checkers should be created first in the **Keypads** collection. +
-  * ** Dual flow** id disabled, the entrance checkers will be considered for both entrance and exit. If enabled, it means the area has differet doors/checkers for entrance and exit. It permits to distinguish entrance and exit events and eventually count the people inside the area. +
-  * **Exit doors** //only visible if **Dual flow** is enabled.// allows you to select the checkers that are used on site to exit this specific area. The checkers should be created first in the **Keypads** collection. +
-  * **Count persons** //only visible if **Dual flow** is enabled.// If enabled, the system will count the number of persons inside the area based on the entrance and exit events. +
-  * **Success enter command** Command to execute in case of successful entrance event. +
-  * **Success exit command** Command to execute in case of successful exit event. +
-  * **Nobody command** //only visit if **Count persons** is enabled.// Command to execute in case nobody is in the area. +
-  * **KNX group force closed** KNX group (1 bit DPT1) to force all doors/checkers to refuse any code. +
-  * **KNX group force open** KNX group (1 bit DPT1) to force all doors/checkers to accept any code. +
-  * **KNX group valid enter** KNX gorup (1bit DPT1) to signal a valid entrance into the area. +
-  * **KNX group valide exit** KNX group (1bit DPT1) to signal a valid exit from the area. +
- +
-==== Timing ==== +
-// information coming soon// +
-==== Roles ==== +
- +
-// information coming soon//+
  
 ====== Logic ====== ====== Logic ======
  • system_objs.txt
  • Last modified: 2024/03/16 09:42
  • by wikiadmin