Aller au contenu

Usure des Fibaro switch


Lucky

Messages recommandés

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

Lien vers le commentaire
Partager sur d’autres sites

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

Lien vers le commentaire
Partager sur d’autres sites

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 ?

Lien vers le commentaire
Partager sur d’autres sites

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 :)

Lien vers le commentaire
Partager sur d’autres sites

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

  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

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 :P

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)

Lien vers le commentaire
Partager sur d’autres sites

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.

  • Like 2
  • Upvote 1
Lien vers le commentaire
Partager sur d’autres sites

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.

  • Like 3
Lien vers le commentaire
Partager sur d’autres sites

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)

Lien vers le commentaire
Partager sur d’autres sites

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

Lien vers le commentaire
Partager sur d’autres sites

@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.

Lien vers le commentaire
Partager sur d’autres sites

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 :D

Lien vers le commentaire
Partager sur d’autres sites

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)

Lien vers le commentaire
Partager sur d’autres sites

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 :D

 

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 :P

Modifié par BenjyNet
Lien vers le commentaire
Partager sur d’autres sites

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 :D

Lien vers le commentaire
Partager sur d’autres sites

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 :)

Lien vers le commentaire
Partager sur d’autres sites

×
×
  • Créer...