Bug voyant sur bouton poussoir Hager

Désolé de ne pas pouvoir plus vous renseigner et surtout merci pour votre aide!

Bonjour,

Quelques question rapidement:

1- Quels sont les liaisons des AG ci-dessous, quelle est leur fonction et à quoi vous servent-ils sous HA.

- name: "Rez de chaussée"
      address: "24/4/134"
      
    - name: "Toutes les lumières"
      address: "24/4/113"

2- Nous allons commencer simplement, pouvez-vous me donner les liaisons des deux AG ci-dessous:

- name: "Bureau"
      address: "24/4/90"
      state_address: "24/4/41"

Merci

PS: Combien d’actionneurs avez vous sur votre bus ?

1- Quels sont les liaisons des AG ci-dessous, quelle est leur fonction et à quoi vous servent-ils sous HA.

- name: "Rez de chaussée"
      address: "24/4/134"
      
    - name: "Toutes les lumières"
      address: "24/4/113"

Les 2 servent seulement à éteindre « les lumières du rez de chaussée » (7 associations) ou « toutes les lumières » de la maison (17 associations). Voici les AG pour les états qui quand ils sont « allumés » laissent le voyant du bouton « extinction » des lumières allumé. Cela me permet de savoir si j’ai une lumière allumée dans la maison.

2- Nous allons commencer simplement, pouvez-vous me donner les liaisons des deux AG ci-dessous:

- name: "Bureau"
      address: "24/4/90"
      state_address: "24/4/41"

Désolé je n’ai pas compris ce que vous entendez par « liaison »?
Est ce cela?


J’ai 2 modules d’actionneurs de 10 pour les lumières.

PS: pour info depuis hier soir j’ai mon voyant de BP qui est allumé pour l’entrée (ainsi que dans HA) alors que la lumière est éteinte. Et si on veut allumer l’entrée il faut appuyer 2 fois sur le BP. il y a donc bien un souci sur les retours d’état mais qu’est ce qui provoque cela? Mystère…

Pendant que je regarde la suite, pour commence pouvez-vous mettre en commentaire c’est deux déclaration puis redémarrer l’intégration, car je pense qu’il faudrait mieux les déclarer comme bouton, mais nous verrons cela après.

   - name: "Rez de chaussée"
      address: "24/4/134"
      
    - name: "Toutes les lumières"
      address: "24/4/113"

Très bien j’ai commenté et redémarrer la passerelle car les voyants étaient en travers…

Je relance si d’autres peuvent m’aider sur mon problème. Mon électricien est passé et me dit que le problème vient de la supervision et non de ma programmation KNX, ce qui ne m’étonne pas forcément puisque les actionneurs sont toujours dans le bon état. Par contre mon bouton poussoir est toujours dans le même état que mon interrupteur dans HA. Auriez vous une idée de comment faire pour voir les requêtes faites par HA au bus directement dans HA (sans passer par ETS) ?
J’ai vu des choses avec Node Red que je n’utilise pas : KNX-Ultimate Viewer et j’ai vu XKNX mais je ne connais pas du tout.
Quelqu’un utilise ?

Merci

Bonjour,
Hier soir je suis resté devant la tv pendant 2H avec la lumière de la cuisine allumée. Quand j’ai voulu la couper dans HA, elle apparaissait « éteinte » alors que je n’avais rien touché.
J’ai donc regarder dans le journal et cela me dit que la cuisine a été éteinte à 23:31:29

En regardant les logs j’ai ça:

2022-08-30 23:31:29.314 DEBUG (KNX Interface) [xknx.raw_socket] Received from ('192.168.1.67', 3671): 06100420001504101b002900bce00204c40f010040
2022-08-30 23:31:29.315 DEBUG (KNX Interface) [xknx.knx] Received from 192.168.1.67:3671 at 1661895089.3151104:
<KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="16" sequence_counter="27" cemi="<CEMIFrame code="L_DATA_IND" src_addr="IndividualAddress("0.2.4")" dst_addr="GroupAddress("24/4/15")" flags="1011110011100000" tpci="TDataGroup()" payload="<GroupValueResponse value="<DPTBinary value="0" />" />" />" />" />
2022-08-30 23:31:29.315 DEBUG (KNX Interface) [xknx.knx] Sending to 192.168.1.67:3671 at 1661895089.315225:
<KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_ACK" Reserve="0" TotalLength="10" />
body="<TunnellingAck communication_channel_id="16" sequence_counter="27" status_code="ErrorCode.E_NO_ERROR" />" />
2022-08-30 23:31:29.315 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="0.2.4" destination_address="24/4/15" payload="<GroupValueResponse value="<DPTBinary value="0" />" />" />
2022-08-30 23:31:29.335 DEBUG (KNX Interface) [xknx.raw_socket] Received from ('192.168.1.67', 3671): 06100420001504101c002900bce00215c40f010040
2022-08-30 23:31:29.335 DEBUG (KNX Interface) [xknx.knx] Received from 192.168.1.67:3671 at 1661895089.3355052:
<KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="16" sequence_counter="28" cemi="<CEMIFrame code="L_DATA_IND" src_addr="IndividualAddress("0.2.21")" dst_addr="GroupAddress("24/4/15")" flags="1011110011100000" tpci="TDataGroup()" payload="<GroupValueResponse value="<DPTBinary value="0" />" />" />" />" />
2022-08-30 23:31:29.335 DEBUG (KNX Interface) [xknx.knx] Sending to 192.168.1.67:3671 at 1661895089.3356216:
<KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_ACK" Reserve="0" TotalLength="10" />
body="<TunnellingAck communication_channel_id="16" sequence_counter="28" status_code="ErrorCode.E_NO_ERROR" />" />
2022-08-30 23:31:29.337 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="0.2.21" destination_address="24/4/15" payload="<GroupValueResponse value="<DPTBinary value="0" />" />" />
2022-08-30 23:31:29.356 DEBUG (KNX Interface) [xknx.raw_socket] Received from ('192.168.1.67', 3671): 06100420001504101d002900bce00214c40f010040
2022-08-30 23:31:29.357 DEBUG (KNX Interface) [xknx.knx] Received from 192.168.1.67:3671 at 1661895089.357145:
<KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="16" sequence_counter="29" cemi="<CEMIFrame code="L_DATA_IND" src_addr="IndividualAddress("0.2.20")" dst_addr="GroupAddress("24/4/15")" flags="1011110011100000" tpci="TDataGroup()" payload="<GroupValueResponse value="<DPTBinary value="0" />" />" />" />" />
2022-08-30 23:31:29.357 DEBUG (KNX Interface) [xknx.knx] Sending to 192.168.1.67:3671 at 1661895089.3572598:
<KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_ACK" Reserve="0" TotalLength="10" />
body="<TunnellingAck communication_channel_id="16" sequence_counter="29" status_code="ErrorCode.E_NO_ERROR" />" />

Déjà je présume une erreur dans ETS : Les adresses 24/4/134 et 24/4/113 ne devraient pas être en 1bit mais en 1octet et doivent correspondre à des scènes.
Il faut donc changer tout ça :

  1. virer toutes ces 2 adresses liées aux participants
  2. Dans la partie « adresses de groupe » d’ETS, attribuer à 24/4/134 et 113 le DPT 17.001 (scène number)
  3. sur le BP de commande, attribuer non pas la valeur « swich off » mais la valeur scène et leur donner un numéro : la scène 1 sera liée à 113, la 2 à 134
  4. faire pareil avec les actionneurs en rajoutant la scène sur chaque sortie

Et tu penses que cela solutionnerait mon problème d’état sur mes lumières « Salon » et « Séjour » ? Je ne maitrise pas ETS donc désolé si mes questions paraissent bêtes.

Pour en avoir le coeur net, tu lances l’outil diagnostic d’ETS , onglet moniteur de groupe, et dans le champ adresse de groupe, tu mets celle du retour d’état des lampes salon et séjour. Puis clik sur « démarrer » et « lire ». Si la valeur est désactivée quand c’est éteint, c’est que le paramétrage dans ETS est bon, donc le problème viendrait plutôt de HA.
Note : dans le diagnostic, la valeur doit changer quand tu appuies sur le bouton mural ON/OFF

Je viens de faire un test car j’ai vu que ma lumière du salon était au statut « éteinte » dans HA alors qu’elle est bien allumée.
J’ai cela dans ETS :


Du coup c’est bien à « Off » donc éteint dans ETS on est d’accord ?

J’ai ensuite réappuyé sur l’interrupteur pour éteindre réllement. C’est donc passé à « Allumé » sur HA (icône). J’ai donc réappuyé pour éteindre et réappuyé encore une fois pour « Allumé » réellement et que cela corresponde dans HA. Voici le résultat de la manip :

Ce qui m’embête, c’est que je ne vois pas le nom de la source : Quel participant envoie sur le bus l’adresse 24/4/11 ?

Peux-tu faire une capture d’ecran dans les adresses de groupes pour que je puisse voir à quels participants cette adresses est liée ? Avec les flags visibles. exemple :

Je suppose que le 0.2.241 c’est HA puisque je l’ai fait depuis l’application Companion via l’interrupteur. C’est peut être pour cela qu’il n’y a pas de nom de source.

Voici pour l’AG 24/4/111 :

C’est normal que ça bugue.
Tu as mis dans state_address la commande des interrupteurs, or il aurait fallu y mettre le retour d’état qui n’est envoyé que par l’actionneur.
Dans le module variateur, tu crées une adresse 1bit que tu relies à l’objet 22 du TXA663 (indication d’état ON/OFF), et c’est elle qu’il faut mettre en state dans HA
Par rapport à ton problème de voyant qui doit être éteint quand toutes les lumières sont éteintes, là c’est un peu différent en ce sens qu’il faut passer par un module logique. Peut être que HA le fait, mais l’idée c’est de déclarer que si la somme de toutes les sorties est supérieure ou égale à 0, alors ton voyant est allumé, sinon éteint.

J’ai repris le paramétrage fait par mon électricien sous Hager TXA100 via une reconstruction depuis l’application Hager/Berker Easy2ETS dans ETS. Il y a peut être eu des choses qui n’ont pas été reprises correctement ? Je n’ai jamais rien modifié sous ETS de peur de tout péter au niveau de la programmation des participants (selon mon électricien). Cela m’a juste servi à récupérer les AG pour paramétrer HA. Donc j’avoue que cela me fait un peu peur…

Envoie une capture d’écran des GAD liées au TXA663, je te dirai

Voici les AG sur le module de variation et les 2 actionneurs.
TXA663 :


.
Module 1 :

Module 2 :


ok
Je ne te cache pas que j’ai du mal à comprendre la logique de programmation automatique du module TXA100 Hager.
Concrètement j’aurai configuré la sortie 2 (lumière salon) ainsi dans HA :

  • name: « Salon »
    address: « 2/4/7 »
    state_address: « 24/4/7 »
    brightness_address: « 2/4/6 »
    brightness_state_address: « 2/4/8 »

Ce que tu peux aussi faire sans aucun risque, c’est rajouter l’objet « scène » dans la sortie2 du TXA663

Sur un BP de commande, tu lui assignes également la fonction "scène (ici exemple avec un wxt316):

Dans les objets de groupe, tu vas retrouver ça pour le BP :

et ça pour le 663 :

Et tu leur donnes une adresse de groupe libre nommée extinction salon, ou extinction générale si tu reproduis le mêmes schéma sur plusieurs sorties.

C’est aussi simple que ça!

Je précise également que les BP ne peuvent envoyer qu’une seule scène, tandis que les actionneurs peuvent en recevoir jusqu’à 64. Ce qui est logique puisqu’une scène correspond à un état prédéfini d’une ou plusieurs sortie(s).

Je viens de tester de changer l’adress dans HA mais cela ne fonctionne pas. J’ai ça :

  • name: « Salon »
    address: « 24/4/111 » => address: « 2/4/7 » ne fonctionne pas
    state_address: « 24/4/7 »
    brightness_address: « 2/4/6 »
    brightness_state_address: « 24/4/8 »

J’avoue ne pas arriver à tout comprendre. Je t’ai écrit par MP en parallèle.