Usure des Fibaro switch

[Lucky 7]

Bonjour,

 

J'ai une scene qui éteind des Fibaro switch tous les soirs (qu'ils soient allumés ou déjà éteints).

Pensez-vous qu'éteindre souvent un switch déjà éteint va l'user ?  si oui, il est peut-être utile de faire des scènes plus intelligentes...

 

Merci

[Invité chris6783]

Bonjour

Je dirais non car le relais est déjà à son état de repos et ne connaîtra aucune solicitation électrique ou mécanique

Envoyé de mon SM-G930F en utilisant Tapatalk

[jojo 2 620]

moi, il me semble que @Did avait dit une fois que ça usait le relais quand-même de lui dire OFF, alors que déjà OFF (de la même manière que s'il faisait ON -> OFF). Alors j'ai systématiquement fait un test dans mes scènes/VD avant de modifier un status.

@Did, oui ou non ?

[BenjyNet 1 200]

Mais non, absolument pas ! La sortie du µC est à l'état haut soit 3.3v et commande un relais. Si tu lui envoies un ordre d'état haut il restera à l'état, il n'y aura pas de changement sur la sortie, tout simplement - le µC s'amuse pas à faire un Off-On-Off pour le plaisir rapidement

[jojo 2 620]

merci, très bonne nouvelle. Et c'est donc qqch de spécifique au module, et qui ne dépend pas de la box, encore mieux !

[Lazer 8 486]

Et puis tu t'en fous en fait, les relais sont donnés pour plus de 10000 commutations à vide, autant dire qu'avec 1 fois par jour, tu auras foutu le module à la poubelle avant que le relai ne colle.

[jojo 2 620]

oui, mais ça je n'y crois pas.

Car j'ai remplacé mes spots halogènes par des led (pas des chinoises, des osram) qui étaient supposer durer beaucoup plus longtemps. je n'ose plus compter combien j'en ai déjà remplacées depuis 6 ans, alors que jamais aucun problème avec les halogènes ....

Alors je suis devenu TRES septique par rapport aux promesses marketting

[Did 1 722]

 Non non, pas du tout, et surtout si tu lui demande d'éteindre alors qu'il y est déjà, aucune usure.

 

[jojo 2 620]

tu dis surtout, cela voudrait dire qu'il serait préférable de faire le test avant d'allumer ?

[Did 1 722]

 Oui, et par opposition à quand tu le mets en marche où là, il y a un décompte du nombre de manœuvres.

 

[Lazer 8 486]

Il y a 13 heures, jojo a dit :

oui, mais ça je n'y crois pas.

Car j'ai remplacé mes spots halogènes par des led (pas des chinoises, des osram) qui étaient supposer durer beaucoup plus longtemps. je n'ose plus compter combien j'en ai déjà remplacées depuis 6 ans, alors que jamais aucun problème avec les halogènes ....

J'avais bien précisé "à vide" en gras pourtant

Pour les LED, même de marque, il y a une électronique, qui pollue forcément plus le signal électrique qu'un simple halogène (résistif pur)

J'ai un FGS 211 (3kW) qui pilote un radaiteur de 1400W depuis 4 ans avec un thermostat SRT321 en PID, donc plusieurs 10zaines de commutations chaque jour (sauf en été), le relai fonctionne comme au premier jour malgré la charge relativement importante.

 

Après comme dit par Benjy et Did, si tu ouvre un relai qui est déjà ouvert, l'usure est nulle.

C'est pour ça que je ne me prend pas la tête, je demande l'ouverture du relai sans vérifier, ça n'a aucun impact sur l'usure, et au moins tu es certain que ton scénario est simple à écrire, et à exécuter (KISS...)

 

Il y a 13 heures, jojo a dit :

Alors je suis devenu TRES septique par rapport aux promesses marketting

Justement là ce n'est pas du marketing, c'est une donnée du constructeur du relai issu du datasheet en PDF. Donc fiable, puisque les conditions du test sont clairement indiquées (à vide, en charge, quel courant, quelle température, etc)

[BenjyNet 1 200]

Les FGS2x3 ont maintenant une commutation lorsque l'alternance 220v passe par le 0v (le fameux zero-crossing commutation) et ça par contre c'est très important car ça évite les problèmes de relais collés à cause des étincelles lors des commutations.

[Lazer 8 486]

Excellent ça, merci de la précision BenjyNet

 

Ils sont forts chez Fibaro quand même.... (en électronique, parce que l'informatique ce n'est pas leur truc....)

[PITP2 1 593]

Je me permets juste d'indiquer qu'il est quand même plus propre de tester avant l'état (ON ou OFF) du point à commander juste pour ne pas surcharger le réseau Zwave.

Cela peut être anecdotique sur une petite installation mais sur des plus importantes cela peut éviter des problèmes.

[jojo 2 620]

ça c'est un argument massue !

[Lazer 8 486]

C'est un excellent argument, mais il faut relativiser.... le sujet de la discussion portait sur 1 activation par jour ! Ce n'est pas ça qui va surcharger le réseau.

 

Ce n'est pas la même chose qu'un capteur qui se réveille toutes les minutes ou un ordre Z-Wave envoyé toutes les minutes.... dans ce cas là, il faut faire très attention à la saturation du réseau (qui se traduit par des latences de plus en plus importantes, voire des ordres qui n'arrivent jamais).

 

Perso sur mes 70 modules, je n'ai jamais eu de souci (sauf une fois quand un vieux module RGBW avait buggué après que j'ai trop joué avec les programmes enregistrés... ça a fait planter mon réseau pendant 5 minutes, mon HC2 étant encore en v3)

[Lucky 7]

Merci à tous pour vos réponses

il y a 46 minutes, PITP2 a dit :

Je me permets juste d'indiquer qu'il est quand même plus propre de tester avant l'état (ON ou OFF) du point à commander juste pour ne pas surcharger le réseau Zwave.

Cela peut être anecdotique sur une petite installation mais sur des plus importantes cela peut éviter des problèmes.

Tester l'état ne charge par le réseau Zwave ?

 

Merci

[Lazer 8 486]

Non car la HC2 ne fait qu'interroger sa propre base de données locale.

 

Par contre, forcer un "polling" du module, là oui, ça interroge réellement le module, donc ça utilise le réseau Z-Wave.

[PITP2 1 593]

@BenjyNet , @Lazer a répondu il va trop vite :-)

 

Alors je vais préciser encore quelque chose sur le pourquoi de ma préférence pour tester.

Sur les installations ou l'environnement est "hostile", plusieurs étages et murs en "dur" pas en placco, il y a de nombreux sauts et souvent des ré-émissions de trames ce qui induit une charge plus conséquente du réseau Zwave.

Ainsi je privilégie toujours un contrôle de l'état (BDD) du module avant toute action.

 

@BenjyNet, merci pour l'info sur le zero-crossing commutation. Je n'avais pas vu cette info.

[BenjyNet 1 200]

Ouais grillé  J'ai même pas eu le temps de rédiger...

Mais pour revenir à ce que tu dis.. pourquoi il y aurait émission de trame si tu demandes un Off alors que le module est déjà sur Off. La HC2 le sait avec la BDD, pourquoi elle reémettrait quelque chose sur le reseau zwave ? Il y aura émission uniquement si le module doit changer d'état. Enfin moi je le vois comme ça... ou alors c'est codé comme un pied

[PITP2 1 593]

Eh eh tu as raison cela a peut être évolué mais ce n'était pas le cas il y a deux ans de mémoire.

D'ailleurs j'avais à l'époque demandé à Steven pour son GEA d'implémenter nativement ce contrôle et je crois qu'il l'avait intégré ... (A confirmer)

[Lazer 8 486]

C'est toujours le cas, il y a bien un transfert même si le module est déjà sur OFF.

 

Je viens de valider avec un Dimmer v2 en 4.170.

[BenjyNet 1 200]

Ouais donc dans ce cas alors effectivement il pourrait y avoir une surcharge du réseau... comme quoi c'est bien codé avec les pieds

 

Edit : En fait le principe est de forcer le polling sur le module qui, lui, renvoie son état.... et donc dans ce cas, aucun intérêt de stocker l'état dans la BDD

Modifié 9 avril 2018 par BenjyNet

[Lazer 8 486]

Moi ça ne me choque pas, tu demandes une action, le contrôleur l'effectue.

 

Si tu écries un programmes en LUA, à toi de faire cette vérification si tu ne veux pas surcharger le réseau.... en fait c'est l'utilisateur qui peut coder avec ses pieds si il le souhaite

[BenjyNet 1 200]

Oui tu demandes une action ok, mais ton code lua, tu dois bien avoir un interpreteur... et c'est à lui justement de savoir si faut demander l'état au module ou pas, suivant ce qui est stocké dans la BDD. Enfin moi je le vois comme ça le fonctionnement, effectivement c'est peut être pas ça