Fonctions personnalisées ?

[teebex]

Bonsoir, 

J'ai une petite expérience en domotique pour avoir joué il y a 4-5 ans avec Zwave et un IPX800. Aujourd'hui, seule mon installation IPX a survécu, le changement de piles des composants ZWave m'ayant lassé.

Je vais faire construire prochainement et j'étudie la manière de mettre en place les prochains automatismes dans ma future maison. J'ai terminé le e-Campus et je sillonne ce forum (très intéressant au demeurant) pour comprendre l'approche décentralisée de knx. Je n'ai pas encore acheté ETS car je n'ai pas encore compris comment intégrer des logiques simples.

Prenons un exemple pour illustrer mes lacunes. Supposons que je veuille  

1. pouvoir allumer la lumière de mon couloir avec un bouton poussoir pour créer une ambiance lumineuse
   
2. que ce couloir s'allume automatiquement lorsque la luminosité est trop faible
   
3. que l'intensité lumineuse soit dépendante de l'heure dans la journée
   

Le cas 1 me semble simple : je relie l'action du bouton poussoir (1 des 4 d'un Jung LS 5074 TSM) sur un des switches d'un MDT AMI-1216.02.

Le cas 2 est déjà trop complexe pour moi. J'imagine utiliser un détecteur de passage et le connecter à ce même switch. Mais comment évaluer la condition sur la luminosité ? Le détecteur de passage doit-il contenir un capteur d'intensité lumineuse ou puis-je en utiliser un autre ? Comment programmer si passage détecté et lumière < x lux alors allumer la lumière sinon ne rien faire?

Cas 3, on corse les choses en ajoutant un intrus : j'ai défini mes heures de sommeil sur mon smartphone et quand je suis sensé dormir, j'aimerais que la lumière soit tamisée. Là les questions sont encore plus nombreuses : depuis un device knx, puis-je interroger un service extérieur ? Sinon comment puis-je stocker un état ?

J'ai découvert 3 lignes sur les fonctions, mais j'ai beau les lire en français (https://support.knx.org/hc/fr/articles/2...rticipants) ou en anglais (https://support.knx.org/hc/en-us/article...th-devices) je ne vois pas comment utiliser ce prémisse d'API. 

En dehors des solutions à mes études de cas, auriez-vous de la lecture à me conseiller, notamment sur les bonnes pratiques ?

Merci d'avance, et pardon si le sujet a déjà été abordé, mais je n'ai rien trouvé.

[fabric24]

Bonjour
Pour le cas numéro 2
Un capteur de luminosité après autant prendre un détecteur

Cas 3
Des capteurs de présence intègrent des objets jour nuit, comme certains inter pour leurs diminuer l'éclairage
A ça il faut rajouter une horloge ou superviseur qui enverra AG sur cet objet

Les fonctions dont tu parles c'est pour simplifier le répétitif mais pour un petit projet ce n'est pas forcément utile

Au départ je pensais que tu parlais de fonctions logiques
Dans tous les cas c'est faisable sans aucunes fonctions

[richardpub]

Regarde les sujets qui traitent de ABB ABA/S1.2.1 et des fonctions logiques. 
Sinon préfères les détecteurs de présence pour les zones où on ne sait pas à l'avance combien de temps on va rester (j'ai des placards dans le couloir, et je vais y ranger des choses) et les détecteurs de mouvement pour des zones où l'on ne fait que passer (couloir de distribution de pièces)

[teebex]

Merci pour vos réponses si rapides.

@fabric24, oui mon interrogation porte sur les fonctions logiques, comment et où les écrire et quels les éléments qu'elles peuvent intégrer. Comme je n'ai pas compris l'utilité des fonctions personnalisées, je pensais qu'il fallait passer par là.

En fait je crains que vous sur-estimiez mes connaissances.

Pour le cas 2, j'imagine facilement connecter le détecteur au switch : tout mouvement détecté allumera la lumière. C'est l'intégration de la condition portant sur la lumière ambiante que je ne vois pas. Si le capteur de luminosité est intégré au capteur de mouvements, je peux imaginer qu'il est possible de les associer avec une condition au sein du même participant avant d'envoyer le message vers le switch. Mais est-ce la réalité ? De même, si le détecteur de luminosité (DL) n'est pas intégré au détecteur de mouvement (DM), ce dernier (DM) peut-il s'abonner aux changements de luminosité détectés par le DL et conditionner l'envoi de la commande au switch à la dernière valeur de luminosité connue ?

@richardpub, merci pour la précision sur les détecteurs de présence et les détecteurs de mouvements. Je vais me plonger dans les sujets qui traitent de ABB ABA/S1.2.1. @Ives m'avait déjà conseillé de les étudier sur un autre forum. Je n'ai pas encore creusé cette voie car pour moi elle va à l'encontre de la décentralisation et, a priori, elle est moins ouverte que node-red par exemple (désolé, je viens du monde du soft).

[richardpub]

@richardpub, merci pour la précision sur les détecteurs de présence et les détecteurs de mouvements. Je vais me plonger dans les sujets qui traitent de ABB ABA/S1.2.1. @Ives m'avait déjà conseillé de les étudier sur un autre forum. Je n'ai pas encore creusé cette voie car pour moi elle va à l'encontre de la décentralisation et, a priori, elle est moins ouverte que node-red par exemple (désolé, je viens du monde du soft).

Cela n'empêche pas d'utiliser node-red mais l'avantage c'est que ca tourne sans serveur en plus.

[teebex]

A la lecture de sa documentation, l'ABB ABA/S1.2.1 est une belle machine à états. J'ai particulièrement apprécié le soin apporté à son atterrissage en cas de panne de courant. Cela doit sûrement faciliter les choses lors du rétablissement de la situation.

Je suis moins fan de son langage propriétaire (quelle est sa pérennité?), de son peu d'ouverture (une fonction Get et Post pour lire/écrire une valeur sur un système exogène seraient les bienvenues), et de cette centralisation de la logique (ne va-t-elle pas à l'encontre d'une logique distribuée ?). Il n'empêche que c'est assurément une brique très intéressante pour résoudre des problèmes complexes.

La question que je me pose est "quand dois-je faire appel à cette brique ?". Puis-je m'en passer pour le cas 2 ? Même si le détecteur de mouvement et le capteur de lumière sont dissociés ?

Merci encore pour vos réponses

[fabric24]

Tu réfléchis trop lol
Le detecteur gère seul détection et luminosité
Tu règles dans les paramètres lux et temps allumage et le radar envoi AG à l'actionneur.
Si c'est séparé ils communiquent via AG

Regardes
https://www.mdt.de/EN_Presence_Detector_MR16.html
Il a 3 capteurs qui peuvent gérer 3 zones differentes
Mode jour nuit
Veilleuse

Décentralisé ne veut pas dire tout est séparé, juste qu il n'y a pas de box maître

[teebex]

Tu réfléchis trop lol
...

Euh non, je ne réfléchis pas assez... ou très mal. 

Merci pour le lien. Je viens seulement d'admettre qu'un participant c'est un automate qui ne sait faire que ce que son fabriquant a imaginé qu'on pouvait en faire. Si mon détecteur n'a pas d'interface avec un capteur de luminosité ou si le type de données n'est pas compatible avec le capteur que je possède, je n'ai pas d'autres choix que de

• changer de capteur, 
  
• changer de détecteur ou 
  
• passer par un automate programmable (merci ABB).
  

Rien de dramatique, il faut juste choisir son matériel en connaissance de cause. Et ça peut devenir vite complexe, entre la profusion de fournisseurs, les docs à trouver et l'anticipation des besoins futurs.

Heureusement qu'il y a des forums.

[fabric24]

Bonjour
Pas vraiment un automate,
c'est comme un capteur de présence 230v au lieu de fermer un contact, il envoie une AG
Décentralisé car pas de maître, tout le monde reçoit lit AG du bus, si il l'AG il réagit

[Ives]

Merci pour le lien. Je viens seulement d'admettre qu'un participant c'est un automate qui ne sait faire que ce que son fabriquant a imaginé qu'on pouvait en faire. Si mon détecteur n'a pas d'interface avec un capteur de luminosité ou si le type de données n'est pas compatible avec le capteur que je possède, je n'ai pas d'autres choix que de

C'est la base du KNX, tous les participants sont configurables par ETS dans les limites imposées par le fabricant. C'est pour cette raison, qu'avant d'acheter un produit il est bien de l'intégrer dans ETS pour vérifier toutes les possibilités de configuration offertes.
Je comprends pas ta notion de "données non compatibles", tous les participants KNX "écoutent" le bus et peuvent emmètrent via le adresses de groupe.

[filou59]

Je comprends pas ta notion de "données non compatibles", tous les participants KNX "écoutent" le bus et peuvent emmètrent via le adresses de groupe.

Peu etre a til vu ou entendu dire que certains participant ne travaillait pas avec le meme type de donnée. 
J'ai pas d'exemple en tete mais si un actionneur de chauffage attend un valeur 0-100% et que le regulateur envoi une valeur 0-255, il faut faire une adaptation par exemple.

[teebex]

Gagné @filou59, c'est à ça que je faisais référence : différence de référentiel (0-100) (0-255) ou même différence de longueur de télégramme standard ou étendu. Selon my.knx.org un télégramme étendu ne peut être compris par un récepteur de télégramme standard.

Encore une fois je ne sais pas si cela peut se présenter, mon expérience toute théorique est essentiellement basée sur les infos disponibles ici et sur my.knx.org.

Vous auriez de bonnes lectures à me conseiller ?