Object/Scene/Central Fuction/Blocking

[gkalpers@gmail.com]

Mais maintenant, je veux aussi que cela ferme mes volets et passe mon chauffage en mode veille. Une programmation classique ne le permet pas mais en passant par une scene, je le peux.

Conclusion :
Une scene permet de paramétrer de manière fines (vitesse de variation, niveau de variation, % ouverture ou fermeture de volet, régler des temperatures, mode de fonctionnement, de chauffage, etc...) des éléments disparates le tout en un seul groupe d'adresse.

Concernant les volets, il y a différentes solutions :
- La scène : mais je ne fais jamais de scène dans ETS. C'est trop lourd à mettre en place. Je les réalise dans le serveur en place.
- Utiliser la fonction centrale de l'actionneur des volets qui permet de remonter les volets en envoyant un 0
- Utiliser un 2e canal si le BP te le permet pour envoyer une 2e AG (c'est moins courant)
- Piloter cela dans un module logique (ie : Serveur)

Je préfère de trèèèèèèès loin créer les scènes dans un serveur car
- plus simple à créer;
- plus simple pour le client pour les modifier ;
- il n'y aura pas de modifications de la scène parce qu'un invité a appuyé longtemps sur le BP KNX qui permet l'apprentissage...
- Des serveurs (X1 Gira) permettent à l'utilisateur de créer lui-même la scène qu'il veut sans que l'intégrateur ne l'ait envisagée. (clin d'oeil à FIlou )
- Possibilités d'utiliser une horloge qui appelle la scène également.

Voila pour mon avis

[*]central functions : je ne sais pas ce que c'est, je pensais que c'était un concept openhab (de mémoire).

[*]
Cela dépend des actionneurs, c'est la fonction qui permet via un seul objet de piloter toutes (ou certaines) sorties ON/OFF et/ou Volets.

Blocking object : il empêche le fonctionnement du BP ou l'appel de la scène ou par rapport à un détecteur de mouvement : l'empêche d'activer ou de désactiver la lumière en cas de détection.

Concernant les Flags : je vous déconseille de toucher aux flags liés aux objets. Le seul qui puisse être modifié est le READ pour lire les status au démarrage d'un serveur par exemple.  Le Read ne sert à rien pour informer les boutons KNX de l'état de la sortie pilotée. C'est le retour d'état de la sortie qui l'informe. Le bouton au redémarrage n'ira pas questionner l'actionneur pour lire son état... Il attendra gentiment que l'actionneur lui envoie son retour d'état. 
Le Read sera utilisé pour lire la valeur active si on en a besoin avant qu'elle ne soit envoyée par l'actionneur par exemple.
Lire des status de lumières n'est pas très utiles en règle générale. 1H après le redémarrage, les status seront à jour . Par contre, lire le status de chauffage ou les températures mesurées au démarrage du serveur peuvent être plus intéressants...

Bonne amuse dans votre développement de projet