Bonjour @fgtoul,
En électronique, il y a un paquets de façon de limiter les parasites (filtre passe-haut, filtrage de l’alim ou augmentation de la puissance etc)
En informatique, une simple boucle de temporisation avant de prendre en compte le signal suivant suffit.
Avant google était mon ami", maintenant chatgpt est mon ami (mais pas en mode bourrin en mode « aide moi à retrouver plus vite l’info dans mon cerveau qui devient de plus en plus lent » …j’en vois déjà venir certains…! 
)
Ce qui peut-être intéressant c’est : "est-ce que la tuile « switch » passe un algo filtre que n’aurait pas le lien direct ? Si oui, est-ce transposable sur le code de traitement du lien direct ?
Chatgpt : écris une fonction filtrage logiciel : si le signal est lu par un microcontrôleur ou un système embarqué, appliquer un filtrage logiciel ou une détection de fronts pour ignorer les variations rapides dues au bruit.
Fonction en C : Filtrage logiciel et détection de fronts
Voici une implémentation en C pour un filtrage logiciel et une détection de fronts. Ce type de fonction est couramment utilisé pour les microcontrôleurs ou les systèmes embarqués pour nettoyer les signaux bruités avant de les traiter.
#include <stdbool.h>
// Filtrage logiciel pour un signal bruité
bool filter_signal(bool current_input, unsigned int debounce_delay_ms, unsigned int sampling_interval_ms) {
static bool last_state = false; // Dernier état stable détecté
static unsigned int stable_time = 0; // Temps durant lequel l’état est stable
static unsigned int elapsed_time = 0; // Temps écoulé depuis le dernier changement
// Vérifie si l'état a changé
if (current_input != last_state) {
elapsed_time = 0; // Réinitialise le temps si changement détecté
} else {
elapsed_time += sampling_interval_ms;
// Si l'état reste stable pendant "debounce_delay_ms", le considère comme valide
if (elapsed_time >= debounce_delay_ms) {
stable_time = elapsed_time; // Met à jour le temps stable
return current_input; // Retourne l'état stable
}
}
last_state = current_input; // Met à jour le dernier état observé
return last_state; // Retourne l'état précédent
}
// Détection de fronts (montant et descendant)
typedef enum {
NO_EDGE, // Pas de changement
RISING_EDGE, // Front montant détecté
FALLING_EDGE // Front descendant détecté
} SignalEdge;
SignalEdge detect_edge(bool current_input) {
static bool previous_state = false; // Dernier état observé
SignalEdge edge_detected = NO_EDGE;
if (current_input != previous_state) {
// Front montant
if (current_input == true) {
edge_detected = RISING_EDGE;
}
// Front descendant
else {
edge_detected = FALLING_EDGE;
}
}
previous_state = current_input; // Met à jour l'état précédent
return edge_detected; // Retourne le type de front détecté
}
Explications :
Fonction filter_signal:
Cette fonction implémente un debounce logiciel pour éliminer les variations rapides du signal.
Paramètres :
current_input : L'état actuel du signal (0 ou 1).
debounce_delay_ms : Durée minimale pendant laquelle le signal doit rester stable pour être considéré comme valide.
sampling_interval_ms : Intervalle entre les lectures successives du signal.
Retourne l'état filtré et stable du signal.
Fonction detect_edge:
Cette fonction détecte les fronts montants (passage de 0 à 1) et les fronts descendants (passage de 1 à 0).
Paramètres :
current_input : L'état actuel du signal.
Retourne un des trois types de transitions :
NO_EDGE, RISING_EDGE, ou FALLING_EDGE.
Utilisation :
Voici un exemple d’utilisation des deux fonctions :
#include <stdio.h>
#include <unistd.h> // Pour la fonction usleep
int main() {
// Exemple de signal bruité
bool noisy_signal = {0, 0, 1, 1, 0, 1, 1, 1, 0, 0};
size_t signal_length = sizeof(noisy_signal) / sizeof(noisy_signal[0]);
// Paramètres de filtrage
unsigned int debounce_delay = 50; // En millisecondes
unsigned int sampling_interval = 10; // Intervalle d'échantillonnage
for (size_t i = 0; i < signal_length; i++) {
bool filtered = filter_signal(noisy_signal[i], debounce_delay, sampling_interval);
SignalEdge edge = detect_edge(filtered);
// Afficher le signal filtré et les fronts détectés
printf("Signal: %d, Filtré: %d, Front: %s\n", noisy_signal[i], filtered,
edge == RISING_EDGE ? "Montant" :
edge == FALLING_EDGE ? "Descendant" : "Aucun");
usleep(sampling_interval * 1000); // Simuler un délai d'échantillonnage
}
return 0;
}
Sortie attendue :
Pour un signal bruité comme celui-ci : {0, 0, 1, 1, 0, 1, 1, 1, 0, 0}, le code peut produire une sortie similaire :
Signal: 0, Filtré: 0, Front: Aucun
Signal: 0, Filtré: 0, Front: Aucun
Signal: 1, Filtré: 1, Front: Montant
Signal: 1, Filtré: 1, Front: Aucun
Signal: 0, Filtré: 0, Front: Descendant
Signal: 1, Filtré: 1, Front: Montant
Signal: 1, Filtré: 1, Front: Aucun
Signal: 1, Filtré: 1, Front: Aucun
Signal: 0, Filtré: 0, Front: Descendant
Signal: 0, Filtré: 0, Front: Aucun
Ce code peut être utilisé dans des microcontrôleurs (Arduino, STM32, etc.) ou des systèmes embarqués pour traiter les signaux bruités provenant d’interrupteurs, capteurs ou autres sources.
Préconisations faites car le lien direct en BT posait problème en l’occurrence ?
Dans le cas ou un inter ou poussoir est relié directement au tableau c’est du TBT câblé en BT.
Moi ce qui m’intéresse c’est que dans un cas de figure ou en rénovation si il est impossible de repasser du TBT sans tout casser ou si on veut garder le câblage BT en cas de revente cela peut permettre d’avoir de la domotique qui fonctionnes sur l’existant ! 
Après, il y a les normes…qui des fois évoluent en arrière (câblage 1.5 pour les prises avec le nombre de prises augmentées, il y a 10 on étaient pas dans les normes maintenant on l’est !)
Il ne s’agit pas d’inciter mais de dire "Le cat7 est préconisé, dans le cas ou c’est pas possible de passer du cat7, il y a possibilité d’utiliser le câblage 1.5 existant mais dans ce cas il est préférable ou semble préférable de passer par un scénario et une tuile « switch » et pas par le lien direct entrée digitale=>relais qui peut fonctionner MAIS sans que le produit soit mis en cause si ce n’est pas le cas ! ".
Dans la le cas du neuf ou d’une rénovation à faire à destinée domotique, on est d’accord ! Mais dans le cas de revente cela peut-être un frein et donc la réversibilité peut être un choix.
