17/01/2023, 21:47:21
(29/10/2019, 15:36:58)Lokidor a écrit :(29/10/2019, 09:30:22)filou59 a écrit : Il y a 2 chose a voir :
1: Quand tu demandes a un participant de mettre a dispo un valeur, il faut parfois spécifier comment la valeur va être envoyé.
Sur Demande
Périodiquement
Les 2 ...
2: Ensuite il faut vérifier les Flags de l'objet en question.
Pour pouvoir lire un objet il faut au minimum : C-R-T
C:Communication
R:Read=Lecture
T:Transmission
OK, je teste ça dès que possible.
Par contre j'avais pas osé toucher aux flags, ayant compris que c'est un gros morceau à apprendre (que je n'ai pas démarré) et que c'est potentiellement sensible... Je risque pas de casser un truc ?
@Jonathan007 : j'ai vu oui, et les champs sont aussi affichés dans la colonne de droite. Mais le champ est vide tout de même.
Salut,
Les flags ne doivent pas être modifiés si on ne comprend pas leurs utilités...
(ça a été détaillé dans pas mal de postes)
En gros :
- On peut activer le flag R (Lecture) sur une objet qui renvoie un état ou une mesure. (quand le flag 'T" est activé de base).
- On n'active pas le flag R sur un objet qui attend une commande (= flag "W" activé)
Si on veut faire un monitoring pour lire les valeurs d'adresses de groupes, il faut que l'objet qui envoie la valeur à lire ait son flag 'R' activé. Si de base, il n'est pas activé, il faut sélectionner l'objet et activé le "R".
Injecter l'application et ça devrait fonctionner. ("Devrait" car certains modules mal conçus n'enverront pas leur valeur même si vous avez activé le flag "R" - Heureusement, c'est rare...)
Concernant le problème de détecteur, FIlou a tout expliqué comme d'hab
L'avantage de pousser chaque objet dans une adresse de groupe est de pouvoir analyser précisément ce qui est envoyé par le détecteur et à quel moment.
Ca aide à comprendre/découvrir un produit KNX que l'on ne maitrise pas.
Bonne recherche