zoroastre:
Yep!
Je suis un peu surpris lorsque l'on parle de fiabilité qu'on arrive à multiplier les composants. On finit par multipier les probalités de pannes, c'est un non sens !!!
Pas vraiment d'accord. :~
Je suis d'accord sur le fait de multiplier les composants multiplie les probabilités de pannes (logique), mais ici nous nous parlons de pannes locale à 1 ou n composants, panne contrôlée et facilement identifiés, le fait qu'un composant (indépendant) sois en panne n’empêche pas les autre de fonctionné.
J'utiliserai comme analogie le développement orienté objet qui a pour but de supprimer aux maximum les dépendances entre objets ,un objet n'entraine pas l'autre dans son erreur, sauf si lié (voir uml composition-agregation), la raison d'être de ce type de développement est justement la fiabilité , différent paterne on été étudier pour supprimer ses dépendance et c'est ce que j'applique ici.
Dans cette analogie j'en veux pour preuve le langage java (objet strict), langage le plus utilisé en entreprise pour ça fiabilité objet.
Edit: je viens de penser à une autre analogie propre au développement arduino, imagine les lib (Ethernet, spi, stepper, ...) toute dans un seul fichier, un seule classe ...
Une autre analogie pour le cas contraire serait la voiture par exemple dont tout composants s'articule autour d'un seul composant le bsi (on vas le comparé à la solution 1 arduino), c'est lui seul qui actionne et gère le bon fonctionnement de chaque composants genre interrupteur qui commande une vitre via celui-ci, he be rien que l'autoradio peux mettre toute la voiture en rade (déjà vu).
zoroastre:
Lors de l'installation de deux composants identiques à un instant t, par exemple, il y a de fortes probabilités qu'ils développent les mêmes maladies au même moment, meurent le même jour.
Là je suis d'accord, déjà eu le cas par exemple avec deux disque dure identique acheté aux même moment et en panne à 2 jours d’intervalle 2 ans plus tard ... =(
zoroastre:
Pour envisager du meilleur abord cet aspect et sans réellement parler du facteur économique, il reste deux solutions viables pour assurer une maintenabilité de l'installation (on n'echaperra pas à la panne), soit on envisage de doubler l'équipement maitre, soit on s'assure d'avoir un stock de pièce de rechange prés à l'emploi. Généralement, on prend en compte les deux aspects en fait, avec comme prérogative d'assurer une disponibilité maximale et de réduire au mieux les temps de dysfonctionnement.
Déjà prévu et pensé également, doubler le composant maître et autres comme un arduino mini par exemple ou contrôleur format dip qu'il suffirait juste d'enfiché sur pcb (du module complet) comme on l'aurais fais avec un fusible dans le coffret divisionnaire.
zoroastre:
Je pense que si l'on veut s'assurer du fonctionnement d'un élement, il faut envisager une technologie autre que l'élement de réference : un poste informatique peut contrôler le bon fonctionnement du programme arduino (et des modules intrasèques) grace à une communication relativement simple et fiable. L'arduino peut également vérifier que la communication est effective avec l'informatique et alerter l'usager. C'est un exemple simple !
Possibilité d'avoir un arduino ou autre également comme cerbère du système, c'est tout à fais envisageable.
zoroastre:
Je trouve en l'état le projet fort complexe et quelques peu coûteux en définitive. J'ai même l'impression que la souplesse d'installation et d'utilisation s'en retrouvent pénalisées.
Je trouve aux contraire qu'il est fort simple et surement beaucoup plus simple que développé une solution en 1 seul bloc et devoir géré le tout en même temps (debug, collision,..) , je préfères réglé 10 problème 1 par 1, étape par étape, que d'essayé le tout en 1 fois.
N'oublions pas non plus qu'il sagit d'une installation domestique, pas d'une guirlande de noël, on y trouve pas la même complexité évidement.
Pour le couts lorsque je compare aux solution professionnel qui prévois qu'une installation complète peux aller de 10 à 15% de la valeur du bien, je me dis que la solution évoqué ici est dérisoire ...
zoroastre:
J'acquiesse avec enthousiasme sur le choix d'un bus Rs485 que j'utilise actuellement pour piloter mes cartes relais 8 canaux (8 relais/carte).
Le seul regret relatif à mes cartes et c'est peut être en définitive le fond du problème dans une installation domotique est de ne pas pouvoir interroger de l'état actuel d'un relais.
Je suis persuadé que si nous pouvions connaitre à chaque instant l'état de nos équipements, quelques soient leurs technologies, leurs non 'communicatitivités' initiales, nous balayerons d'une main tout problème, l'arduino, unique, officierait comme maître incontestable. Le système serait 'bouclé'(langage d'automaticien).
Oui le rs-485 semble être la solution la plus adapté et utilisé (confiance).
Ici le bus sera communiquant (logique d'un côté ), donc l'état de chaque modules sera communiqué en temps réel par action à un module contrôleur genre web ou en local au module (donc possibilité de bdd et autres par exemple).
zoroastre:
La domotique est une technologie communicante de fait, mais son attrait principal est de pouvoir bénéficier d'un meilleur contrôle de son habitation. Et ce 'meilleur contrôle' doit s'appliquer également à l'installation domotique elle-même.
un meilleur contrôle de chaque composante de son habitation je dirais et quoi de mieux que le fait de pouvoir contrôler facilement chaque composante de l’installation domotique elle-même indépendamment des l'un des autres ?
J'appliquerais le proverbe "chercher une aiguille dans une botte de foin" ici.
Je conçois que cette façon de voir peux paraître déroutante, illogique, usine à gaze, etc, qu'on peux se dire "pourquoi faire simple quand on peux faire compliqué" (j'y vois le contraire), mais comme je l'ai déjà dit je n'ai rien inventé je ne me base que sur de l'existant, solutions testé et éprouvées depuis longtemps, ça fait plusieurs année que je m’intéresse aux sujet et ça a même été le sujet principal de mon travail de fin d'études (développement d'une application modulaire serveur de domotique en java).
Je ne critique pas tes propos et suggestions qui sont interessant, elles permettent le débats et l’évolution du projet.